Linking public key of device to information during manufacture

ABSTRACT

A method in which information pertaining to a device ( 104 ) generating digital signatures ( 122 ) is reliably identified includes manufacturing ( 102 ) devices in a secure environment ( 114 ) and for each device ( 104 ) before it is released from the secure environment: creating a public-private key pair ( 116, 118 ); storing the private key ( 116 ) within the device ( 104 ) for utilization in generating a digital signature ( 122 ) for a message ( 122 ); and linking the public key ( 118 ) to a Security Profile ( 120 ) of the device ( 104 ). The devices ( 104 ) then are released from the secure environment ( 114 ) and a digital signature ( 122 ) is received from somewhere ( 108 ) in the world ( 106 ). The message ( 122 ) is authenticated using a suspect public key ( 124 ) and the suspect public key ( 124 ) is compared with the linked  114  public keys ( 118 ). A Security Profile ( 120 ) of the genuine device ( 104 ) to which belongs the private key ( 116 ) used in generating the digital signature ( 122 ) is identified when the public key ( 124 ) matches a linked public key ( 118 ). A risk that the message ( 122 ) is fraudulently signed is determined.

I. CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This patent application claims priority in the United Statesunder 35 U.S.C. 119, and under the Paris Convention worldwide, to thebenefit of the filing date of Wheeler et al. U.S. provisional patentapplication serial No. 60/223,076, which was filed on Aug. 4, 2000, andwhich is incorporated herein by reference. This application alsoincorporates herein by reference each of three international patentapplications and three U.S. patent application to Anne and Lynn Wheelerfiled concurrently herewith on Aug. 6, 2001, in the U.S. Patent &Trademark Office and bearing serial number PCT/US01/41587 (entitled“Person-Centric Account-Based Digital Signature System”) and Ser. No.09/923,179 (entitled “Account-Based Digital Signature (ABDS) System”);serial number PCT/US01/41562 (entitled “Entity Authentication inElectronic Communications by Providing Verification Status of Device”)and Ser. No. 09/923,075 (entitled “Modifying Message Data and GeneratingRandom Number Digital Signature Within Computer Chip”); Ser. No.09/923,213 (entitled “Manufacturing Unique Devices That Generate DigitalSignatures”); and serial number PCT/US01/24563 (entitled “TrustedAuthentication Digital Signature (TADS) System”).

II. FIELD OF THE PRESENT INVENTION

[0002] The present invention generally relates to electroniccommunications and, in particular, to devices that generate digitalsignatures associated with electronic communications.

III. BACKGROUND OF THE PRESENT INVENTION

[0003] As used herein, an electronic communication (“EC”) is consideredto be any communication in electronic form. ECs have become an integralpart of transacting business today, especially with the growth of theInternet and e-commerce. An EC can represent, for example, a request foraccess to information or a physical area, a financial transaction, suchas an instruction to a bank to transfer funds, or a legal action, suchas the delivery of an executed contract.

[0004] Over recent years, digital signatures also have become animportant part of e-commerce. The origination of a digital signaturegenerally comprises: (1) the calculation of a message digest—such as ahash value; and (2) the subsequent encryption of the message digest. Themessage digest is encrypted by an electronic device generally using aprivate key of a key pair used in public-private key cryptography (alsoknown as asymmetric cryptography). The resulting ciphertext itselfusually constitutes the digital signature, which typically is appendedto the message to form the EC. The second part of originating thedigital signature—encrypting with a private key—is referred to herein as“generating” the digital signature, and the combination of the two stepsis referred to herein as “originating” the digital signature.Furthermore, while the generation of the digital signature isconventionally understood as the encryption of the message digest, it iscontemplated herein that generating the digital signature also mayinclude simply encrypting the message rather than the message digest.Digital signatures are important because any change whatsoever to themessage in an EC is detectable from an analysis of the message and thedigital signature. In this regard, the digital signature is used to“authenticate” a message contained within the EC (herein referred to as“Message Authentication”).

[0005] For example, a message digest may be calculated by applying ahashing algorithm to the message. The hashing algorithm may be appliedeither within the device or external to the device with the resultinghash value then being transmitted to the device for generation of thedigital signature. In order to perform the Message Authentication inthis example, the recipient of the EC must know or be able to obtainboth the identity of the hashing algorithm applied to the message aswell as the public key (“PuK”) corresponding to the private key used toencrypt the message digest. With this knowledge, the recipient appliesthe appropriate hashing algorithm to the message to calculate a hashvalue, and the recipient decrypts the digital signature using the publickey. If the hash value calculated by the recipient equals the hash valueof the decrypted digital signature, then the recipient determines thatthe content of the message contained in the EC was not altered intransmission, which necessarily would have changed the hash value.

[0006] In performing Message Authentication, the recipient alsoauthenticates the sender of the EC, in so much as the recipient therebyconfirms that the sender of the EC possessed the private keycorresponding to the public key used successfully to authenticate themessage. This is one type of entity authentication and is based on whatthe sender “has” (herein referred to as “Factor A EntityAuthentication”). Factor A Entity Authentication is useful when therecipient of the EC has trusted information regarding the identity ofthe owner of the private key. Such trusted information may arise from adigital certificate issued by a trusted third-party that accompanies theEC and binds the identity of the private key owner with the public key.This trusted knowledge also may comprise actual knowledge of theidentity of the private key owner, such as in the case where therecipient itself has issued the private key or the device containing theprivate key to the owner.

[0007] As will be appreciated, trust in the digital signature systemdepends upon the legitimate possession and use of the private key, i.e.,upon the sender of the EC actually being the private key owner. Afraudulent use of a private key to generate a digital signature of an ECcurrently cannot be detected through the above-described MessageAuthentication and Factor A Entity Authentication procedures. Thedigital signature system therefore is susceptible to fraud if a privatekey of a device is stolen, either by physical theft of the devicecontaining the private key, or by discovery of the private key thereinand subsequent copying and use in another device capable of generatingdigital signatures.

[0008] To guard against fraudulent use of a device through theft of thedevice itself, a personal identification number (PIN), password, orpassphrase (collectively referred to herein as “Secret”) is typicallyprestored within the device and must be input-into the device before itwill operate to generate digital signatures. Alternatively, the Secretis shared with the recipient beforehand and, when the EC later is sentto the recipient, the Secret also is sent to the recipient inassociation with the message. In the first case, verification of theSecret authenticates the user of the device (herein “UserAuthentication”), and in the second case, verification of the Secretauthenticates the sender of the EC (herein “Sender Authentication”). Ineither case, confirmation of the Secret represents entity authenticationbased on what the user or sender “knows” (herein “Factor B EntityAuthentication”). Another security feature that guards againstfraudulent use of the device through physical theft include theverification of a biometric characteristic—like a fingerprint—of theuser of the device or sender of the EC. This type of authentication isbased on what the user or sender “is” (herein “Factor C EntityAuthentication”). As with the Secret, a biometric value is eithermaintained within the device for User Authentication, or is shared withthe recipient beforehand for Sender Authentication by the recipient. Toguard against discovery of a private key and subsequent copying and usein another device, devices are manufactured with electronic shielding,zeroization, auditing, tamper evidence and tamper response, and othersecurity features that serve to safeguard the private key (and otherprotected data) contained therein.

[0009] Such security features of devices include hardware, software, andfirmware, and are well known in the art of manufacturing secure computerchips and other devices having cryptographic modules. The requirementsof such security features are specified, for example, in FederalInformation Processing Standards Publication 140-1, SecurityRequirements for Cryptographic Modules, US DOC/NBS, Jan. 11, 1994(herein “FIPS PUB 140-1”), which is incorporated herein by reference andwhich is available for download athttp://csrc.nist.gov/publications/fips; and Federal InformationProcessing Standards Publication 140-2, Security Requirements forCryptographic Modules, US DOC/NBS, May 25, 2001 (herein “FIPS PUB140-2”), which is incorporated herein by reference and which isavailable for download at http://csrc.nist.gov/publications/fips. FIPSPUB 140-1 and 140-2 also define security levels that may be met by adevice based on the device's security features, with each of thesedefined security levels generally representing a various level ofdifficulty—in terms of time and money—that would be encountered inattempting to discern a private key of a device. Currently, foursecurity levels are defined with security level 4 being the highestlevel of security available.

[0010] Specifications for such security features also are set forth inTrusted Computing Platform Alliance Trusted Platform Module ProtectionProfile Version 0.45, TRUSTED COMPUTING PLATFORM ALLIANCE, September2000; Trusted Platform Module (TPM) Security Policy Version 0.45,TRUSTED COMPUTING PLATFORM ALLIANCE, October 2000; and TCPA PCImplementations Specification Version 0.95, TRUSTED COMPUTING PLATFORMALLIANCE, Jul. 4, 2001, which are incorporated herein by reference(collectively “TCPA Documents”), and which are available for download athttp://www.trustedpc.com. and Common Criteria for Information TechnologySecurity Evaluation, Smart Card Protection Profile, Draft Version 21.d,SMART CARD SECURITY USER GROUP, Mar. 21, 2001, which is incorporatedherein by reference hereinafter “Smart Card Protection Profile”), andwhich is available for download at http://csrc.nist.gov.

[0011] The particular features of a device that safeguard againstdiscovery of a private key and other protected data are referred toherein as “security characteristics” of the device. The particularfeatures of a device that, safeguard against unauthorized use of thedevice by authenticating the user are referred to herein as“authentication capabilities” of the device. The “security features” ofa device (including a cryptographic module or TPM) comprise the securitycharacteristics and authentication capabilities as well as othersecurity features of the device, the requirements of which are specifiedin the above cited references.

[0012] Unfortunately, while the aforementioned security featuresgenerally reduce the risk of fraud within the digital signature systemoverall, a recipient of any one particular EC including a digitalsignature may be unfamiliar with the device used to generate the digitalsignature and, therefore, be unable to gauge the risk of whether thedigital signature was generated fraudulently, either through theft ofthe device or discovery of the private key.

[0013] Of course, if the recipient possesses a shared secret or abiometric value of the sender for performing Sender Authentication, thenthe recipient may determine that the digital signature was notfraudulently generated assuming that the shared secret or biometricvalue was not stolen. However, this type of protection by the recipienthas significant drawbacks and is not always used by the recipient. Forexample, if the Secret or biometric value is communicated to therecipient in association with a message for Sender Authentication by therecipient, then the Secret or biometric value first must have beenshared with the recipient beforehand and safeguarded by the recipient aspart of an established, preexisting relationship; consequently, arecipient having no prior existing relationship with the sender isunable to perform Sender Authentication.

[0014] Another drawback is that the sharing of the Secret or biometricvalue with the recipient exposes the recipient to liability and exposesthe Secret or biometric value itself to a greater risk of theft anddissemination. The transmission of the Secret or biometric value forverification carries with it the risk of interception and discoveryduring transit. Upon receipt, the Secret or biometric value must besafeguarded by the recipient, which inherently gives rise to a risk oftheft from the recipient. This is especially significant in thecorporate context where a rogue employee may steal the safeguardedSecret or biometric value (insider fraud historically has been thegreatest threat). The potential damages also are extensive when theSecret or biometric value is stolen. Since it is difficult for anindividual to remember multiple Secrets for multiple recipients, it iscommon for the same Secret to be used with different recipients. Thetheft of the Secret from one recipient thereby compromises the SenderAuthentication performed by all of the recipients, at least until theSecret is changed for each recipient. In the case of the theft of abiometric value, the damages are even more severe, as a sender'sbiometric characteristic cannot be changed and, once lost, potentiallycompromises any future Sender Authentication therewith.

[0015] Accordingly, a recipient generally is unable to gauge the risk ofwhether a digital signature was generated fraudulently when no secret orbiometric value is shared between the sender and the recipient. Instead,a recipient must rely upon blind trust in accepting that the device usedto generate the digital signature has not been stolen and in acceptingthat the device used to generate the digital signature has sufficientsafeguards to protect its private key from discovery and use.

[0016] A need therefore exists for a method by which a recipient mayreliably identify a risk of whether a digital signature has beengenerated fraudulently using a stolen private key (whether stolen byphysical theft of the device or discovery of the private key itself),whereby the recipient may protect itself against fraud. In this regard,a need also exists for a method by which a recipient of an EC includinga digital signature may reliably determine at any given time the currentlevel of security of the device to which belongs the private key used togenerate the digital signature. A need also exists for a method by whicha recipient of an EC may reliably determine the safeguards of suchdevice that protect against fraudulent use thereof.

IV. SUMMARY OF THE PRESENT INVENTION

[0017] The present invention generally comprises the linking in areliable manner of a public key of a device that generates digitalsignatures using asymmetric cryptography to other information regardingthe device within an environment in which the device is manufactured. Asused herein, the “other information” comprises at least one of securityfeatures and manufacturing history of the device, and preferablyincludes both security features and manufacturing history of the device(herein collectively referred to as “Security Profile”).

[0018] As used herein, the “authentication capabilities” of the deviceinclude those components that perform either or both of Factors B and CEntity Authentication with regard to authentication of the user of thedevice. Furthermore, the “manufacturing history” of the devicepreferably includes a recording of manufacturing attributes of thedevice, such as the manufacturer of the device; all specificationsapplicable to the device; manufacture date of the device; location ofmanufacture; batch identifier of the device; serial number or partnumber of the device; security of the manufacturing facility; physicalinstantiation of the device regarding layout and process geometry;software identification and release date; operating parameters of thedevice, including voltage and frequency ranges; and identification ofall enabled hardware and software security features of the device. Themanufacturing history of the device also preferably includes thecryptographic characteristics, key generation characteristics, andrandom number generator characteristics of the device.

[0019] A. First Aspect of the Present Invention: Identifying PuK-LinkedInformation of Device Generating Digital Signatures

[0020] A first aspect of the present invention includes the linking of apublic key of a device with other information within the environment ofits manufacture and then the later identifying of the other informationregarding the device after the release of the device from themanufacturing environment based upon its public key. By considering suchinformation later identified, a recipient is able to gauge a risk orlikelihood of whether a digital signature using the private keybelonging to the device was generated fraudulently.

[0021] In accordance with the preferred methods of the first aspect ofthe present invention, the device is manufactured in a secureenvironment (i.e., an environment having a sufficient security rating soas not to compromise the security level of any device manufactured insuch environment). Furthermore, the information linked with the publickey of the device comprises the Security Profile of the device.Accordingly, the recipient is able to determine a current security levelof the device based on the identified security features of the device.The recipient also is able is to gauge a risk of whether the private keyof the device was compromised based on the identified securitycharacteristics of the device, and the recipient is able to gauge a riskof whether the device containing the private key was fraudulently usedbased on the identified authentication capabilities of the device.Finally, the recipient is able to evaluate the stated security featuresof the device based upon the identified manufacturing history of thedevice.

[0022] In preferred methods of the first aspect of the presentinvention, before a, manufactured device is removed from the secureenvironment, a public-private key pair is created within the device andthe public key is exported and linked to the Security Profile of thedevice within one or more databases maintained within the secureenvironment (herein collectively “secure database”). In particular, oneof the keys—the public key—is recorded in the secure database by thedevice manufacturer or other trustworthy entity (“Secure Entity”), andthe other key—the private key—is preferably retained within themanufactured device and safeguarded against discovery. The public keyalso is retained within the device and is exportable upon demand. TheSecurity Profile of the manufactured device is recorded in the securedatabase, and the record therefor is indexed or mapped to thecorresponding public key, thereby reliably linking together both thepublic key and Security Profile of the device. In this case, the uniqueidentifier is stored within the device and is exportable upon demand.Moreover, since each public key is unique—at least to a high degree ofprobability—the mapping in the secure database is one-to-one.Alternatively, the public key and Security Profile are indexed to aunique identifier of the device within the secure database, therebyreliably linking together the public key and Security Profile of thedevice, whereby an assurance level of the device may be determined.

[0023] Subsequently, when an EC is received by a recipient that includesa digital signature generated by a suspect device and the message isauthenticated utilizing a suspect public key, the recipient identifiesthe Security Profile linked to the suspect public key as pertaining tothe actual manufactured device to which belongs the private key used togenerate the digital signature of the EC (herein “genuine device”).Then, whether the digital signature was generated fraudulently can begauged by the recipient based upon the known Security Profile for thegenuine device. Specifically, the risk of whether the private keyretained within the manufactured device has been compromised—and thuswhether the suspect device is the genuine device—can be gauged based onthe identified security characteristics of the genuine device, and therisk of whether the genuine device has been fraudulently used can begauged based on the identified authentication capabilities of thegenuine device. These evaluations also can be qualified based on theidentified manufacturing history of the device, as appropriate.

[0024] In alternative preferred methods of the first aspect of thepresent invention, a public-private key pair is created and the publickey of the device is linked to the Security Profile of the device bycombining the public key with the Security Profile into a record thatthen is digitally signed by the Secure Entity. The record and digitalsignature together form a “Security Certificate,” which also is importedinto the device for safekeeping with the private key. The digitalsigning of the record by the Secure Entity in the secure environmentreliably links the Security Profile of the manufactured device and itspublic key.

[0025] Subsequently, when a digital signature is generated by the devicefor inclusion in an EC, the Security Certificate also is included in theEC. Upon receipt and successful authentication of the message using thesuspect public key set forth in the Security Certificate, the recipientauthenticates the Security Certificate in the EC utilizing a public keyof the Secure Entity. Upon successful authentication thereof, therecipient reliably identifies the Security Profile of the genuine deviceto which belongs the private key used in generating the digitalsignature of the EC. Then, whether the digital signature was generatedfraudulently can be gauged by the recipient based upon the knownSecurity Profile for the genuine device. Specifically, the risk ofwhether the private key retained within the manufactured device has beencompromised—and thus whether the suspect device is the genuinedevice—can be gauged based on the identified security characteristics ofthe genuine device, and the risk of whether the genuine device has beenfraudulently used can be gauged based on the identified authenticationcapabilities of the genuine device. These evaluations also can bequalified based on the identified manufacturing history of the device,as appropriate.

[0026] B. Second Aspect of the Present Invention: EstablishingPuK-Linked Account Database

[0027] A second aspect of the present invention includes establishing aninitial PuK-linked account database. A method in accordance with thisaspect of the present invention includes manufacturing devices thatgenerate digital signatures and, for each manufactured device befor itis released from the environment of its manufacture: creating a pair ofkeys used in asymmetric cryptography; storing one of the keys within themanufactured device for utilization in generating a digital signaturefor an electronic message; and recording the other key and otherinformation in a database maintained within the environment such thatthe information is linked with the key in the database. The manufactureddevices then are distributed to a plurality of users. The users to whichthe manufactured devices are distributed may comprise existing customersas well as potential customers of a third-party. Thereafter, thedatabase records of the distributed manufactured devices are identifiedto the third-party as the initial PuK-linked account database of theusers.

[0028] In accordance with the preferred methods of this aspect of thepresent invention, the information with which each key of a device islinked comprises the Security Profile of the respective device, and thedevices for which the Security Profiles are identified are manufacturedin a secure environment. The database also preferably comprises a securedatabase. Furthermore, the keys of each device preferably are generatedand are retained within the device, with the public key preferably beingexportable on demand.

[0029] In preferred methods of this aspect of the present invention, theidentifying of the database records includes communicating from thesecure environment in a secure manner the database records for thedistributed manufactured devices as the initial PuK-linked accountdatabase of the third-party. In this regard, the database records arecommunicated in a manner having a security rating greater than thesecurity level of any manufactured device to which the database recordspertain. Indeed, the security rating should be proportional to theaggregate risk presented by all of the individual devices to which thedatabase records pertain. Such a manner includes generating a digitalsignature for the database records and then communicating the databaserecords and digital signature to the third-party.

[0030] When the third-party receives the PuK-linked database as theinitial PuK-linked account database of the users, it may be updated withspecific information of the users that is provided by each user. Inassociating information specific to a user with a record of the initialPuK-linked account database, Factor A Entity Authentication preferablyis used based on the user digitally signing a message with the privatekey of the manufactured device. Alternatively, the initial PuK-linkedaccount database may be merged with a preexisting account database ofthe users maintained by the third-party that contains user-specificinformation, or the initial PuK-linked account database may bemaintained separately from but indexed with such a preexisting accountdatabase of the users. In such case, the third-party preferablyauthenticates each user as being the correct user for the respectiverecords of the user in the account databases before such association ismade. Accordingly, Factor A Entity Authentication preferably is usedwith respect to the record of the user in the PuK-linked accountdatabase, and other entity authentication techniques are used forauthenticating the user with respect to the record in the accountdatabase. Such other techniques may include questioning the user aboutspecific-account information in the record or requiring the user toprovide a Secret, such as the maiden name of the mother of the user.

[0031] C. Third Aspect of the Present Invention: Establishing InitialPuK-Linked Account Database Record

[0032] A third aspect of the present invention includes establishing aninitial PuK-linked account database record of a user with a plurality ofaccounts maintained by different third-parties. A method in accordancewith this aspect of the present invention includes manufacturing devicesthat generate digital signatures and, for each manufactured devicebefore it is released from the environment of its manufacture: creatinga pair of keys used in asymmetric cryptography; storing one of the keyswithin the manufactured device for utilization in generating a digitalsignature for an electronic message; and recording the other key andother information in a database maintained within the environment suchthat the information is linked with the key in the database. One of themanufactured devices then is distributed to the user. Thereafter, thedatabase record of the distributed device is identified to each of thethird-parties as being the initial PuK-linked account database record ofthe user. The user may be a customer or potential customer of eachthird-party.

[0033] In accordance with the preferred methods of this aspect of thepresent invention, the information with which the key of the device islinked comprises the Security Profile of the device, and the device ismanufactured in a secure environment. The database in which the key andSecurity Profile are linked also preferably comprises a secure database.Furthermore, the keys preferably are generated and are retained withinthe device, with the public key preferably being exportable on demand.

[0034] In preferred methods of this aspect of the present invention, theidentifying of the initial PuK-linked database record includescommunicating from the secure environment in a secure manner thedatabase record for the device of the user to a third-party at which anaccount of the user is or will be maintained. In this regard, thedatabase records are communicated in a manner having a security ratinggreater than the security level of the manufactured device to which thedatabase record pertains. Such a manner includes generating a digitalsignature for the database record by the Secure Entity and thencommunicating the database record and digital signature to thethird-party.

[0035] When the third-party receives the PuK-linked database record asthe initial PuK-linked account database record of the user, it may beupdated with specific information of the user as provided by the user.In associating user-specific information with the initial PuK-linkedaccount database record of the user, Factor A Entity Authenticationpreferably is used for the initial PuK-linked account database recordbased on the user digitally signing a message with the private key ofthe manufactured d vice. Alternatively, the initial PuK-linked accountdatabase record may be merged with a preexisting account database recordof the user maintained by the third-party that contains user-specificinformation, or the initial PuK-linked account database record may bemaintained separately from but indexed with such a preexisting accountdatabase record of the user. In such case, the third-party preferablyauthenticates the user as being the correct user for both accountrecords before such association. Accordingly, Factor A EntityAuthentication preferably is used in conjunction with other entityauthentication techniques for authenticating a user with respect to theaccount database record. Such other techniques may include questioningthe user about specific-account information in the record or requiringthe user to provide a Secret, such as the maiden name of the mother ofthe user.

[0036] D. Fourth Aspect of the Present Invention: Insuring EC for aTransaction Based on Identified PuK-Linked Information of DeviceGenerating Digital Signatures

[0037] Yet a fourth aspect of the present invention includes theinsuring of a transaction based, at least in part, on the identifiedinformation of a manufactured device that generates digital signaturesin accordance with the first aspect of the present invention. Inparticular, a preferred method in accordance with the fourth aspect ofthe present invention includes the steps of manufacturing devices in asecure environment and, for each manufactured device before it isreleased from the secure environment: creating a pair of keys used inasymmetric cryptography; storing one of the keys within the manufactureddevice for utilization in generating a digital signature for anelectronic message; and linking together in a secure manner the otherkey and the Security Profile of the manufactured device. Themanufactured devices then are released from the secure environment.

[0038] Thereafter, an electronic communication representing thetransaction is sent with a digital, signature generated with a suspectdevice. The electronic communication includes an electronic message anda digital signature generated for the electronic message utilizing thekey stored in one of the manufactured devices. Upon receipt, the messageis authenticated using a public key. The Security Profile linked to thepublic key successfully authenticating the message then is identified asthe Security Profile of the genuine device to which belongs the privatekey used in generating the digital signature, and a monetary guaranteeis provided that the digital signature for the electronic message wasnot generated fraudulently. The monetary guarantee, i.e., the insurance,is provided in exchange for a premium that is based, at least in part,upon an evaluation of the identified security features of the genuinedevice and further may be based on an evaluation of the manufacturinghistory of the device. In this regard, the preferred method furtherincludes assigning a defined risk level to the EC based on theidentified Security Profile, with each defined risk level correspondingto a different premium rate that is charged for the provision of themonetary guarantee.

[0039] E. Fifth Aspect of the Present Invention: Gauging Whether EC onAccount is Fraudulent Based on PuK-Linked Information of DeviceGenerating Digital Signatures

[0040] A fifth aspect of the present invention includes gauging a riskof whether an EC including a digitally signed message representing atransaction on an account is fraudulent based not only on informationlinked with the public key of a device used to generate the digitalsignature, but also on a transactional history of the account asrecorded by the recipient and, in particular, a history of transactionson the account that were digitally signed herein “transactionalhistory”).

[0041] In a feature of this aspect of the present invention, a pluralityof manufactured devices are distributed to or acquired by a user and thedatabase record for each distributed device is provided to the recipientand associated with the account of the user. Subsequently, for ECs fortransactions on the account that are received by the recipient and thatinclude digital signatures generated by one of the devices, therecipient records the particular details regarding each such transactionin the account. However, rather than generally associating thetransaction details with the overall account, the recipient associatesthe transaction details' with the linked public key used to successfullyauthenticate the message of the EC. Accordingly, for each EC received,the recipient evaluates the potential for a fraudulent EC based not onlyon the information linked with the public key identified in accordancewith the first aspect of the present invention, but also on thetransactional history of digitals signatures authenticated using suchkey as recorded by the recipient. In yet an additional feature, theenvironment in which the digital signature of an EC is generated, ifsuch information is discernable from the EC or otherwise obtainable,also preferably is considered in gauging a risk of whether the EC isfraudulent. For instance, an I/O support element may also digitally signan EC, and information regarding the 110 support element linked to thepublic key of the I/O support element may be identified in accordancewith the first aspect of the present invention. Furthermore, in anotherfeature, the authentication techniques performed (if any) when a linkedpublic key was associated with the account of the user are recorded inthe account record and are considered in gauging a risk of whether aparticular EC is fraudulent.

[0042] F. Sixth Aspect of the Present Invention: Service forDisseminating PuK-Linked Information of Device Generating DigitalSignatures

[0043] In accordance with a sixth aspect of the present invention, anentity (herein “Central Key Authority”) maintains PuK-linked accountregistration information for a user (herein “Registration Information”).The Registration Information includes the public key and one or more ofthe following types of information relating to a particular device ofthe user that generates digital signatures: the identity ofthird-parties with which the user has PuK-linked accounts for thedevice; information linked with the public key of the device inaccordance with the first aspect of the present invention; user-specificinformation; and, if applicable, the authentication techniques that wereemployed in verifying the user-specific information maintained by theCentral Key Authority.

[0044] In accordance with this aspect of the present invention, theCentral Key Authority disseminates some or all of the RegistrationInformation, as appropriate, to a third-party. Registration Informationis disseminated when the user has an account with a third-party—ordesire to establish an account with a third-party—and desires to sendECs with messages representing transactions on the account that aredigitally signed using the device. The dissemination of the RegistrationInformation also occurs, for example, when Registration Information witha third-party has become outdated for a particular account. Furthermore,the dissemination of the Registration Information may be in accordancewith the third aspect of the present invention.

V. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Further features and benefits of these aspects of the presentinvention will be apparent from a detailed description of preferredembodiments thereof taken in conjunction with the following drawings,wherein like references refer to like elements, and wherein:

[0046]FIG. 1 illustrates a preferred system in which a first preferredmethod of the first aspect of the present invention is practiced;

[0047]FIG. 2 illustrates a flowchart of steps performed within a secureenvironment in accordance with the first preferred method of the firstaspect of the present invention;

[0048]FIG. 3 illustrates a communication sequence in identifying aSecurity Profile of a device in accordance with the first preferredmethod of the first aspect of the present invention;

[0049]FIG. 4 illustrates a flowchart of steps performed by a suspectdevice originating a digital signature in an EC in accordance with thefirst preferred method of the first aspect of the present invention;

[0050]FIG. 5 illustrates a flowchart of steps performed by a recipientin accordance with the first preferred method of the first aspect of thepresent invention;

[0051]FIG. 6 illustrates a flowchart of steps performed by a SecureEntity in accordance with the first preferred method of the first aspectof the present invention;

[0052]FIG. 7 illustrates a flowchart of steps performed within thesecure environment in accordance with a second preferred method of thefirst aspect of the present invention;

[0053]FIG. 8 illustrates a communication sequence in identifying aSecurity Profile of a device in accordance with the second preferredmethod of the first aspect of the present invention;

[0054]FIG. 9 illustrates a flowchart of steps performed by a suspectdevice originating a digital signature in an EC in accordance with thesecond preferred method of the first aspect of the present invention;

[0055]FIG. 10 illustrates a flowchart of steps performed by a recipientin accordance with the second preferred method of the first aspect ofthe present invention;

[0056]FIG. 11 illustrates a flowchart of steps performed by a SecureEntity in accordance with the second preferred method of the firstaspect of the present invention;

[0057]FIG. 12 illustrates a flowchart of steps performed within thesecure environment in accordance with a third preferred method of thefirst aspect of the present invention;

[0058]FIG. 13 illustrates a communication sequence in identifying aSecurity Profile of a device in accordance with the third preferredmethod of the first aspect of the present invention;

[0059]FIG. 14 illustrates a flowchart of steps performed by a suspectdevice originating a digital signature in an EC in accordance with thethird preferred method of the first aspect of the present invention;

[0060]FIG. 15 illustrates a flowchart of steps performed by a recipientin accordance with the third preferred method of the first aspect of thepresent invention;

[0061]FIG. 16 illustrates a flowchart of steps performed by a SecureEntity in accordance with the third preferred method of the first aspectof the present invention;

[0062]FIG. 17 illustrates a system related to the second aspect of thepresent invention in which a third-party provides goods and/or servicesto customers and maintains a customer account database in conjunctiontherewith;

[0063]FIG. 18 illustrates a preferred system in which a preferred methodof the second aspect of the present invention is practiced;

[0064]FIG. 19 illustrates database records of an initial PuK-linkedaccount database in accordance with the preferred method of the secondaspect of the present invention;

[0065]FIG. 20 illustrates a PuK-linked account database of customerscomprising the database records of FIG. 19 after having been updatedand/or merged by the third-party representing an Internet serviceprovider;

[0066]FIG. 21 illustrates a PuK-linked account database of customerscomprising the database records of FIG. 19 after having been updatedand/or merged by the third-party representing a financial institution;

[0067]FIG. 22 illustrates a preferred system in which a preferred methodof the third aspect of the present invention is practiced;

[0068]FIG. 23 illustrates a preferred system in which a first preferredmethod of the fourth aspect of the present invention is practiced;

[0069]FIG. 24 illustrates a communication sequence in accordance withthe first preferred method of the fourth aspect of the presentinvention;

[0070]FIG. 25 illustrates a flowchart of steps performed by a suspectdevice originating a digital signature of an EC in accordance with thefirst preferred method of the fourth aspect of the present invention;

[0071]FIG. 26 illustrates a flowchart of steps performed by a FinancialInstitution in accordance with the first preferred method of the fourthaspect of the present invention;

[0072]FIG. 27 illustrates a flowchart of steps performed by an InsuringEntity in accordance with the first preferred method of the fourthaspect of the present invention;

[0073]FIG. 28 illustrates a flowchart of steps performed by a SecureEntity in accordance with the first preferred method of the fourthaspect of the present invention;

[0074]FIG. 29 illustrates a communication sequence in accordance with asecond preferred method of the fourth aspect of the present invention;

[0075]FIG. 30 illustrates a flowchart of steps performed by a suspectdevice originating a digital signature in an EC in accordance with thesecond preferred method of the fourth aspect of the present invention;

[0076]FIG. 31 illustrates a flowchart of steps performed by a FinancialInstitution in accordance with the second preferred method of the fourthaspect of the present invention;

[0077]FIG. 32 illustrates a flowchart of steps performed by an InsuringEntity in accordance with the second preferred method of the fourthaspect of the present invention;

[0078]FIG. 33 illustrates a flowchart of steps performed by a SecureEntity in accordance with the second preferred method of the fourthaspect of the present invention;

[0079]FIG. 34 illustrates a communication sequence in accordance with athird preferred method of the fourth aspect of the present invention;

[0080]FIG. 35 illustrates a flowchart of steps performed by a suspectdevice originating a digital signature in an EC in accordance with thethird preferred method of the fourth aspect of the present invention;

[0081]FIG. 36 illustrates a flowchart of steps performed by a FinancialInstitution in accordance with the second preferred method of the fourthaspect of the present invention;

[0082]FIG. 37 illustrates a flowchart of steps performed by an InsuringEntity in accordance with the second preferred method of the fourthaspect of the present invention;

[0083]FIG. 38 illustrates a flowchart of steps performed by a SecureEntity in accordance with the second preferred method of the fourthaspect of the present invention;

[0084]FIG. 39 illustrates a communication sequence in accordance with afourth preferred method of the fourth aspect of the present invention;

[0085]FIG. 40 illustrates a flowchart of steps performed by a suspectdevice originating a digital signature in an EC in accordance with thefourth preferred method of the fourth aspect of the present invention;

[0086]FIG. 41 illustrates a flowchart of steps performed by a FinancialInstitution in accordance with the fourth preferred method of the fourthaspect of the present invention;

[0087]FIG. 42 illustrates a flowchart of steps performed by an InsuringEntity in accordance with the fourth preferred method of the fourthaspect of the present invention;

[0088]FIG. 43 illustrates a flowchart of steps performed by a SecureEntity in accordance with the fourth preferred method of the fourthaspect of the present invention;

[0089]FIG. 44 illustrates an established PuK-linked account database ofcustomers of a third-party representing a financial institution inaccordance with a preferred method of a fifth aspect of the presentinvention;

[0090]FIG. 45 illustrates a flow chart for considering whether, toperform a transaction on an account in accordance with a preferredmethod of the fifth aspect of the present invention;

[0091]FIG. 46 illustrates an account database of a Central Key Authorityin accordance with a sixth aspect of the present invention;

[0092]FIG. 47 illustrates a communication sequence in accordance with apreferred method of the sixth aspect of the present invention;

[0093]FIG. 48 illustrates a flowchart of steps performed by a user inaccordance with the preferred method of the sixth aspect of the presentinvention of FIG. 47;

[0094]FIG. 49 illustrates a flowchart of steps performed by a CentralKey Authority in accordance with the preferred method of the sixthaspect of the present invention of FIG. 47;

[0095]FIG. 50 illustrates a flowchart of steps performed by a firstAccount Authority in accordance with the preferred method of the sixthaspect of the present invention of FIG. 47; and

[0096]FIG. 51 illustrates a flowchart of steps performed by a secondAccount Authority in accordance with the preferred method of the sixthaspect of the present invention of FIG. 47.

VI. DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0097] As a preliminary matter, it readily will be understood by thosepersons skilled in the art that, in view of the following detaileddescription of the devices, systems, and methods of the presentinvention, the present invention is susceptible of broad utility andapplication. Many embodiments and adaptations of the present inventionother than those herein described, as well as many variations,modifications, and equivalent arrangements, will be apparent from orreasonably suggested by the present invention and the following detaileddescription thereof, without departing from the substance or scope ofthe present invention. Furthermore, those of ordinary skill in the artwill understand and appreciate that although steps of various processesmay be shown and described in some instances as being carried out in apreferred sequence or temporal, order, the steps of such processes arenot necessarily to be limited to being carried out in such particularsequence or order. Rather, in many instances the steps of processesdescribed herein may be carried out in various different sequences andorders, while still falling within the scope of the present invention.Accordingly, while the present invention is described herein in detailin relation to preferred embodiments, it is to be understood that thisdetailed description only is illustrative and exemplary of the presentinvention and is made merely for purposes of providing a full andenabling disclosure of the present invention. The detailed descriptionset forth herein is not intended nor is to be construed to limit thepresent invention or otherwise to exclude any such other embodiments,adaptations, variations, modifications and equivalent arrangements ofthe present invention, the present invention being limited solely by theclaims appended hereto and the equivalents thereof.

[0098] A. Overview of the Present Invention

[0099] The present invention generally comprises the linking in areliable manner of a public key of a device that generates digitalsignatures using public-private key cryptography to other informationregarding the device within an environment in which the device ismanufactured. The public-private key pair preferably is generated withinthe device during its manufacture; thereafter, the private key isretained securely within the device and never exported, and the publickey may be retained within the device and exportable upon demandwhenever needed.

[0100] In accordance with all of the aspects of the present invention,the device comprises hardware or firmware and, specifically, comprises acomputer chip, an integrated circuit, a computer-readable medium havingsuitable software therein, or a combination thereof. The device furthermay comprise a physical object such as a hardware token or an embeddedtoken, the token containing such a computer chip, integrated circuitry,or software, or combination thereof. If the device is a hardware token,it preferably takes the form of a ring or other jewelry; a dongle; anelectronic key; a card, such as an IC card, smart card, debit card,credit card, ID badge, security badge, parking card, or transit card; orthe like. If the device is an embedded token, it preferably takes theform of a cell phone; a telephone; a television; a personal digitalassistant (PDA); a watch; a computer, computer hardware; or the like.The device preferably includes a device interface comprising aport—including a wireless communications port, a serial port, a USBport, a parallel port, or an infrared port—some other physical interfacefor communicating with an external electronic apparatus, whether contactor contactless. The device also may include a trusted platform module(TPM) comprising hardware and software components providing increasedtrust in a platform, as set forth and described in the TCPA Documentscited above.

[0101] Some of these devices require use of an I/O support element toenable the device to receive data representing a message, a Secret, or abiometric characteristic. Some of the devices require an I/O supportelement to receive specific types of data but not others. Some of thedevices require use of an I/O support element to transmit informationincluding digital signatures and messages to recipients. Some of thedevices are self-contained and can generate and transmit messages anddigital signatures without the use external apparatuses; some devices,although self-contained, are capable of interacting with such externalapparatuses, such as an I/O support element, if desired. An 110 supportelement may take the form of any number of different apparatuses,depending upon the particular application in which it is used anddepending upon the type of device with which interacts.

[0102] For applications of a device requiring high security, thedevice—or the device in combination with an I/O supportelement—preferably includes the following components: a keypad(alphanumeric), interactive display, or other type of user data entrymechanism (collectively referred to herein as “User Interface”) thatallows a user to compose or modify a message; a User Interface forinputting data representing a Secret (it should be noted that the UserInterface for generating or modifying a message may, but does not haveto, be the same as the User Interface for the entry of the datarepresenting a Secret); a display for showing the message and/or Secretto the user; a scanner or reader for receiving at least one type ofbiometric data for a biometric characteristic of the user, memory forsecurely storing the Secret of the authorized user, biometric data ofthe authorized user, and the private key; a processor or circuitry forverifying input of the Secret of biometric data as being that of theauthorized user, a processor or circuitry for generating or originatingdigital signatures; and a means for outputting from the device andtransmitting information including the message and digital signaturetherefor. Preferably, the device also includes memory for storing andexporting the public key associated with the particular private key, andfor storing types of user information such as account information, userID, and the like. For lower security applications, not all of the aboveelements are necessary.

[0103] The public key linked information in the preferred embodiments ofthe present invention includes the Security Profile of the device. Asdefined above, the Security Profile preferably includes the securityfeatures of the device (including characteristics and authenticationcapabilities), as well as the manufacturing history of the device. It isimportant to know the security features of a device—rather than simply astated security level of the device—as technologies are developed overtime that reduce the effectiveness of such security features and,consequently, result in the decrease of the actual security level of thedevice. Unless upgrades are made, the security features of a device arepermanent while the security level of the device eventually willdecrease over time. By knowing the security features, the appropriatesecurity level of a device may be determined at any given time.Furthermore, by knowing the security characteristics of the device, arecipient is able to gauge a likelihood of whether the private key ofthe device has been compromised, and by knowing the authenticationcapabilities of the device (or lack thereof), a recipient is able togauge a likelihood of whether someone other than the authorized userutilized the device to generate a digital signature. Finally, by knowingthe manufacturing history of a device, the security features of thedevice may be revised as errors, omissions, flaws, security breaches, orpossible improprieties and the like are discovered as having occurredduring the manufacturing of the device.

[0104] A. Identifying PuK-Linked Information of Device GeneratingDigital Signatures

[0105] 1. First Preferred Embodiment

[0106] In accordance with the first aspect of the present invention, andwith reference to FIG. 1, a first preferred embodiment is practicedwithin a first preferred system 100 that includes a secure manufacturingfacility 102, devices manufactured at the facility 102 as represented bydevice 104, the world 106, a recipient 108, and a secure database 110maintained by a Secure Entity 112. The facility 102 and the securedatabase 110 are located within a secure environment 114, whichrepresents any and all locations having a sufficient security rating soas not to compromise the security level of the device 104 manufacturedin the facility 102. As will be apparent, the facility 102 and thesecure database 110 need not be co-located at the same physical locationin order to be within the secure environment 114. Nor must themanufacturer of the device 102 be the Secure Entity 112 that maintainsthe secure database 110, although such possibility is within the scopeof the present invention.

[0107] The relevant manufacturing steps that are performed within thesecure environment 114 are set forth in FIG. 2. With reference to bothFIGS. 1 and 2, a public-private key pair is generated (Step 202) withinthe device 104 during its manufacture in the facility 102 and before thedevice 104 is released from the secure environment 114. Preferably thepublic-private key pair is created with a random number generatordisposed within the device 104 itself. The private key 116 (PrK) isretained within the device 104, while the corresponding public key (PuK)118 is exported (Step 204) from the device 104 and recorded (Step 206)in the secure database 110 before the device 104 is released from thesecure environment 114. If desired, the public key 118 also may beretained (not shown) within the device 104 for later export upon demandafter release of the device 104 from the secure environment 114. Theprivate key 116 is utilized, for example, in generating a digitalsignature (DS) for a message (M) that is communicated to the recipient108. In addition to the public key 118, a Security Profile 120 of thedevice 104 is compiled and recorded (Step 208) in the secure database110 and indexed to the public key 118, whereby the Security Profile 120is retrievable from the secure database 110 based on knowledge of thepublic key 118. The public key 118 and Security Profile 120 are therebysecurely linked together.

[0108] Following population of the secure database 110 with the publickey 118 and Security Profile 120 of the device 104, the device 104 isreleased from the secure environment 114 into the world 106. The securedatabase 110, however, is maintained (Step 210) in the secureenvironment 114 to preserve the integrity of the data recorded therein.Furthermore, following manufacture the security rating of the securedenvironment 114 is maintained at a level that is at least as comparableto, and preferably greater than, the security level of each device 104manufactured at the facility 102 for which the public key 118 andSecurity Profile 120 are maintained in the secure database 110.

[0109] With reference now to FIGS. 3-6, a digital signature (DS) isoriginated (Step 402) for a message (M) somewhere in the world 106 witha suspect device. The suspect device may be the genuine device 104manufactured at the facility 102 of FIG. 1 that is legitimately used,the genuine device 104 that is fraudulently used, or a counterfeitdevice having a replica of the private key 116 of the genuine device104. The digital signature then is combined (Step 404) with the messageto form an EC 122, which is sent (Step 406) to the recipient 108 overany conventional secure or insecure electronic communications network,such as the Internet or a private network.

[0110] The recipient 108 receives the EC 122 (Step 502) and attempts toauthenticate (Step 504) the message using a suspect device public key124. The suspect device public key 124 is provided to the recipient 108and, preferably, is included within the EC 122 that is received by therecipient 108, whereby the recipient 108 may readily attemptauthentication of the message. Alternatively, the suspect device publickey 124 is identified to the recipient 108 before or after receipt ofthe EC 122 in such a manner that the recipient 108 is able to associatethe suspect device public key 124 with the EC 122.

[0111] In any event, if the message successfully authenticates using thesuspect device public key 124, and if the message is the first messageauthenticated using the suspect device public key 124, then therecipient 108 sends (Step 506) the suspect device public key 124 to theSecure Entity 112 that manages the secure database 110 and requests aSecurity Profile associated with that public key 124. Communicationsbetween the recipient 108 and the Secure Entity 112 are by way of anyconventional secure or insecure electronic communications network, suchas the Internet or a private network.

[0112] When the Secure Entity 112 receives (Step 604) the suspect devicepublic key 124 from the recipient 108, the Secure Entity 112 compares(Step 606) the suspect device public key 124 against the exported publickeys maintained in the secure database 110 to determine if there is amatch. If a match is found, then the Security Profile associated withthe matching, exported public key is retrieved and, for the purpose ofmaintaining the integrity of the information during transit, digitallysigned (Step 608) by the Secure Entity 112. The Security Profile anddigital signature therefor create a “Security Certificate” (SC) 126 thatthen is forwarded (Step 610) to the recipient 108. Preferably, thepublic key 118 of the manufactured device 104 matching the suspectdevice public key 124 is included in the Security Certificate 126 forconfirmation by the recipient 108 of the public key 118 to which theSecurity Certificate 126 pertains.

[0113] Upon receipt (Step 508) of the Security Certificate 126 from theSecure Entity 112, the authenticity of the Security Certificate 126 ischecked (Step 510) using a public key 128 (SE PuK) of the Secure Entity112, which preferably has been communicated (Step 602) to the recipient108 beforehand. Subsequently, upon a successful authentication, theSecurity Profile contained in the authenticated Security Certificate 126is identified as the Security Profile 120 of the genuine device 104 towhich belongs the private key 116 used to digitally sign the message ofthe EC 122.

[0114] Thereafter, the recipient 108 gauges the risk of whether the useof the private key 116 of the genuine device 104 to digitally sign themessage of the EC 122 was fraudulent based on the identified SecurityProfile. The Security Certificate 126 also is recorded by the recipient108 in an “in-house” database maintained by the recipient 108, wherebythe same suspect device public key 124 used to authenticate future ECsmay be referenced against this in-house database for identifying theappropriate Security Profile, rather than again sending a request forthe Security Profile to the Secure Entity 112. Accordingly, anotherrequest need not be made unless and until the Security Profile has beenupdated by the Secure Entity 112.

[0115] 2. Second Preferred Embodiment

[0116] Briefly described, in a second preferred embodiment of the firstaspect of the present invention a Secure Entity generates a referencecontaining device public keys and corresponding Security Profiles linkedthereto for a plurality of devices manufactured at a securemanufacturing facility and communicates the reference to a recipient.The reference is embodied in print or electronic media and includes alist of Security Profiles of manufactured devices indexed by theirrespective public keys. Furthermore, the reference preferably isdigitally signed by the Secure Entity, whereby the recipient maysecurely rely upon the information contained in the reference whensuccessfully authenticated with a public key of the Secure Entity.Thereafter, the recipient only need compare each suspect device publickey that successfully authenticates a message against the device publickeys included in the reference, rather than actually send each suspectdevice public key to the Secure Entity for a Security Profile. Therecipient thereby is readily able to identify the Security Profile ofthe genuine device to which belongs the private key used to digitallysign the message.

[0117] With particular reference to FIG. 7, and in accordance with thissecond preferred embodiment, a public-private key pair is created (Step702) within each device during its manufacture and before the devicesare removed from a secure environment 714. The respective private key ofeach device is retained securely within the device, and the respectivepublic key is exported from each device (Step 704) and recorded (Step706) in a secure database together with the respective Security Profileof each device. The respective public key may also be retained withineach device and be exportable upon demand. Each Security Profile isindexed with the exported public key (Step 708) of the respectivedevice, whereby the Security Profile of the device is retrievable fromthe secure database based on the public key. Following population of thesecure database with the public key and Security Profile of the device,the Secure Entity creates and preferably digitally signs (Step 710) areference including the Security Profiles and public keys linkedtherewith for the respective devices. As will be appreciated by one ofordinary skill in the art, all of the Steps 702-710 occur within thesecure environment 714.

[0118] Following release of the devices from the secure environment 714,and with reference now to FIGS. 8-11, a digital signature is originated(Step 902) for a message (M) somewhere in the world 806 with a suspectdevice, and the digital signature is combined (Step 904) with themessage to form an EC 822, which is then sent (Step 906) to therecipient 808. The recipient 808 receives the EC 822 (Step 1004) andattempts to authenticate (Step 1006) the message using a suspect devicepublic key sent within the EC 822 or otherwise provided to the recipient808.

[0119] Upon successful authentication of the message, the recipient 808compares the suspect device public key against the public keys includedin the reference 830 created by the Secure Entity 812. The reference 830is forwarded (Step 1106) to the recipient 808 and received andauthenticated (Step 1002) by the recipient 808 preferably before thereceipt of the EC 822. Also, in order that the recipient 808 mayauthenticate the reference 830, the public key 828 (SE PuK) of theSecure Entity 812 also preferably is communicated (Step 1102) in asecure manner beforehand. Then, if the suspect device public key matchesa public key in the reference 830, the Security Profile of the genuinedevice to which belongs the private key used to digitally sign themessage is identified. Subsequently, the recipient 808 is able to gauge,based on the identified Security Profile, a risk that the private key ofthe genuine device was fraudulently used to digitally sign the messageof the EC 822.

[0120] 3. Third Preferred Embodiment

[0121] In a third preferred method, a Security Certificate isincorporated into a manufactured device itself prior to its release fromthe secure environment of its manufacture. In this regard, and withreference to FIG. 12, a pair of keys are created (Step 1202) within thedevice during its manufacture and before its release from a secureenvironment 1214. The private key is securely retained within thedevice, and the public key is exported (Step 1204) from the device andmay also be retained within the device and be exportable upon demand.The exported public key is combined with a Security Profile of thedevice and digitally signed (Step 1206) by the Secure Entity to form theSecurity Certificate. The Security Certificate then is imported (Step1208) into the device itself and is exportable from the device with adigital signature for inclusion in an EC.

[0122] Thereafter, with reference to FIGS. 13-16, a suspect deviceoriginates (Step 1402) a digital signature for a message (M) somewherein the world 1306. The digital signature and Security Certificate of thedevice are then exported from the device and combined (Step 1404) withthe message to form an EC 1322, which then is sent (Step 1406) to therecipient 1308. Upon receipt (Step 1504) of the EC. 1322 by therecipient 1308, the suspect device public key identified in the SecurityCertificate is used to authenticate (Step 1506) the message, and theSecure Entity's public key 1328—which preferably is communicated (Step1602) by the Secure Entity 1312 and received (Step 1502) by therecipient 1308 beforehand—is used to authenticate (Step 1508) theSecurity Certificate. Upon successful authentication, the SecurityProfile of a genuine device to which belongs the private key used togenerate the digital signature is thereby identified to the recipient1308. Based on the identified Security Profile, the recipient 1308 isable to gauge the risk that the private key of the genuine device wasfraudulently used to digitally sign the message of the EC 1322.Furthermore, because the public key is bound with the Security Profilein the Security Certificate during the manufacture of the device in thesecure environment, the recipient 1308 is able to rely upon the SecurityCertificate corresponding, in fact, to the genuine device.

[0123] Benefits of the third preferred embodiment of the first aspect ofthe present invention include the elimination of the requirement thatthe recipient 1308 transmit a suspect device public key to the SecureEntity 1312, and the elimination of the requirement that the SecureEntity 1312 transmit the a Security Profile directly to the recipient1308. Of course, a disadvantage to this preferred method is that theentire system is compromised if the Secure Entity's private key used todigitally sign Security Certificates is compromised.

[0124] 4. Variations of the Preferred Embodiments

[0125] In the first and second preferred embodiments of the first aspectof the present invention set forth above, the Security Profile of eachdevice is indexed in the secure database to the public key of the deviceand is retrievable from the secure database based on the public key. Ina variation, of these two preferred embodiments (not shown), theSecurity Profile and public key of each device is recorded in the securedatabase and are indexed to a unique device identifier, which maycomprise, for example, an account number written into the device duringits manufacture, a serial number manufactured within the device duringits manufacture, or the like. The device identifier is exportable fromthe device for inclusion with each digital signature generated by thedevice. Upon receipt of an EC including the digital signature and deviceidentifier, a recipient then obtains the suspect device public key bycross-referencing the device identifier with a known database orreference for public, keys and Security Profiles linked therewith. Inthis regard, the recipient forwards the device identifier to a SecureEntity for identifying the suspect device public key and SecurityProfile therefor, or the recipient compares the device identifier in areference published by the Secure Entity that includes public keys andlinked Security Profiles indexed by device identifiers. The methodologyis similar to that described above for the first and second preferredembodiments, the primary difference being that the recipient mustcontact the Secure Entity or check a reference prior to attempting toauthenticate a received message. In the first and second preferredembodiments in which the Security Profile of each device is indexed toits public key, the recipient only need contact the Secure Entity orcheck a reference if the message first authenticates using the suspectdevice public key included with the message.

[0126] In a variation of the first, second, and third preferredembodiments of this aspect of the present invention, the Secure Entityreceives the EC and, itself, identifies the Security Profile of thegenuine device to which belongs the private key used to digitally signthe message. Furthermore, the EC in this case either may be sentdirectly to the Secure Entity or may be forwarded to the Secure Entityby a recipient for gauging of the risk that the private key of thegenuine device was fraudulently used to digitally sign the message.

[0127] Preferably, the steps set forth above with regard to FIGS. 5-6;FIGS. 10-11; and FIGS. 15-16 are computer automated, and the entiresequence of events of each respective group of figures occurs within asmall time interval on the order of magnitude of minutes, if notseconds.

[0128] In view of the foregoing detailed description of preferredembodiments of the first aspect of the present invention, it will beapparent to those having ordinary skill in the art that by: creating therespective public-private key pair of each device within th deviceitself before release from the secure environment of its manufacture;exporting only the public key from the device and retaining the privatekey within the device against the possibility of export; and securelylinking the exported public key of the device with other informationwithin the secure environment of manufacture of the device, each deviceis thereby rendered unique with respect to all of the other devices.Moreover, because of the secure environment in which the devices aremanufactured and the secure linking of the public key with the otherinformation, the uniqueness of the devices may be relied upon bythird-parties—such as future Account Authorities—even though suchthird-parties may not have had any control or involvement in the actualmanufacturing of the devices. The secure binding of the public key witheach device within the environment of the manufacture of the deviceprovides the required trust for relying upon the uniqueness of thedevices, as each device may be authenticated based upon the private keyretained therein, and only therein. Accordingly, the present inventionfurther includes this manufacturing process for devices.

[0129] A benefit this manufacturing process is that it provides theability to transport devices from their place of manufacture toadditional processing facilities where the devices are initialized withregard to particular Account Authorities without high levels of securityotherwise conventionally utilized. For example, armored cars and guardsare routinely used to protect the delivery of credit card and IC cardsupplies to a processing facility for initialization for a particularfinancial institution. Indeed, as a result of the manufacturing processof the present invention, a facility at which additional processingtakes place on behalf of a particular Account Authority now mayauthenticate each device prior to its initialization and independent ofthe transport of the device from the manufacturing facility. Moreover,because of the ability to authenticate a particular device immediatelyfollowing its manufacture and thereafter, the system of using of asingle device for making transactions on multiple accounts maintainedwith different Account Authorities is now enabled with higher levels oftrust not otherwise found in the conventional art.

[0130] B. Establishing Initial PuK-Linked Account Database

[0131] The second aspect of the present invention includes establishingan initial PuK-linked account database and is based partially upon thefirst aspect of the present invention. In this regard, the establishmentof a database for a plurality of manufactured devices as describedabove—wherein each device has a unique record including its public keyand other information regarding the device—represents a database thatmay be built upon in creating an initial PuK-linked account database fora plurality of customers and/or consumers (generically referred toherein as “customers”) of a third-party.

[0132] Specifically, with reference to FIG. 17, a third-party 1732provides services and/or goods 1734 to each of a plurality of customers1736 and, in connection therewith, maintains a database 1738 of accountrecords for the customers 1736. For example, and without limitation, thethird-party 1732 (herein referred to as an “Account Authority”) may be afinancial institution including a bank, finance company, or insurancecompany; merchant; Internet service provider; teleconmunicationprovider; medical provider; government entity; or utility company. Theaccount database 1738 typically is established one account at a time ona per customer basis as each customer 1736 engages the Account Authority1732, and each database record for the customer 1736 typically isindexed within the database 1738 by a unique account number.

[0133] In accordance with the second aspect of the present invention,and with reference to FIG. 18, a predetermined number of devices 1804are manufactured in a secure environment 1814 in accordance with thefirst and second preferred embodiments of the first aspect of thepresent invention. In accordance with the second aspect of the presentinvention, the devices 1804 are earmarked for the Account Authority1732, and database records 1840 in the secure database 1810corresponding to the devices 1804 are communicated in a secure manner1814′ to the Account Authority 1732. The earmarked devices 1804 also aredistributed to the customers 1736 of the Account Authority 1732.

[0134] Upon receipt of the PuK-linked database records 18440 by theAccount Authority 1732, the database records 1840 represent an initialPuK-linked account database for the Account Authority 1732. The databaserecords 1840 preferably include the public keys 1818 of the devices 1804and the Security Profiles 1820 of the devices 1804 as described abovewith respect to the first and second preferred embodiments of the firstaspect of the present invention. Moreover, the database records 1840 arepreferably digitally signed by the Secure Entity 1812 for security intransit from the Secure Entity 1812 to the Account Authority 1732.

[0135] An example of the preferred database records 1840 are shown inFIG. 19. As set forth in the background section above, the SecurityProfile includes security features of the device—specifications forwhich are set forth for example in PIPS PUBS 140-1 and 140-2—as well asa manufacturing history of the device as specified, for example, inSmart Card Protection Profile. Moreover, in accordance with thepreferred embodiments of the present invention the security features ofthe Security Profile include security characteristics and authenticationcapabilities of the device.

[0136] Once received, the Account Authority 1732 updates the PuK-linkedaccount database records with specific information of the customers 1736and their accounts. However, before such an association is made betweena particular customer's account and a record of the initial PuK-linkedaccount database, the particular customer 1736 preferably isauthenticated to the Account Authority 1732 with respect to thatcustomer's account. Accordingly, entity authentication techniques areused for authenticating the customer 1736 with respect to a record inthe account database. Such authentication techniques may includequestioning the particular customer 1736 about specific-accountassociated information in the record or requiring the particularcustomer 1736 to provide a Secret or other entity information, such asthe maiden name of the mother of the customer (Factor B EntityAuthentication).

[0137] Additionally, the Account Authority 1732 preferably verifies thata customer 1736 has received the correct device 1804. The device 1804received by a customer 1736 is identified by having the customer 1736digitally sign a message with the private key of the device 1804 andtransmit the message and digital signature in a respective EC 1822 thatis sent to the Account Authority 1732 for Factor A EntityAuthentication. The Account Authority 1732 authenticates the messageusing a public key of the device 1804 that preferably is included in theEC 1822. Furthermore, upon a successful authentication of the message,the Account Authority 1732 identifies the record in the initialPuK-linked account database corresponding to the public key successfullyauthenticating the message for association with the account of thecustomer 1736.

[0138] If additional security is required, each device may include aninitialization PIN that first must be entered by a customer beforefunctioning. Upon the correct entry of the initialization PIN, eachcustomer preferably then enters a personalization PIN that must beentered, for example, each time the device is used thereafter. Theinitialization PINs preferably are distributed to the customersseparately from the devices. Moreover, the use of an initialization PINand a personalization Pin in each device preferably is included in eachdatabase record as part of the authentication capabilities of therespective device.

[0139] A number of alternative techniques for verifying that thecustomers received the correct cards also could be used. For example,each customer could be required to call a particular number from his orher home and input over the telephone a number printed on eachrespective device in order to effect association of the device with thecustomer's account.

[0140] Once sufficient authentication is completed, thecustomer-specific information may be associated with the PuK-linkedaccount database record in various ways. First, the initial PuK-linkedaccount database record may be merged with a preexisting accountdatabase of the customer maintained by the Account Authority, whichcontains the customer-specific information. Second, the initialPuK-linked account database may be maintained separately from butindexed by an identifier with a preexisting account database of thecustomer containing the customer-specific information. Third, theAccount Authority simply may obtain the customer-specific informationfrom the customer following authentication and update the PuK-linkedaccount database record accordingly.

[0141] This second aspect of the present invention also is useful inestablishing accounts for new customers of the Account Authority. Inthis regard, devices are distributed in the same manner as set forth inFIG. 18, but to potential customers of the Account Authority rather thanto existing customers. However, in this scenario entity authenticationwith respect to preexisting accounts is not required, as new accountsare established by the potential customers. Nevertheless, Factor AEntity Authentication remains important in associating a customer withone of the particular PuK-linked records.

[0142] With respect to the establishment of new accounts, under an“anonymous” framework the manufactured devices are distributed to thecustomers, and the goods and/or services are provided to the customerswithout regard to any customer-specific information, i.e., the goodsand/or services are provided on a per device basis as identified by thepublic key of the device, and are not necessarily on a per customerbasis. Thus, upon successful authentication with a public key of amessage digitally signed by one of the devices, the account identifiedby the public key is activated and nothing further is required.

[0143] On the other hand, under a “personalized” framework each newcustomer provides customer-specific information to the AccountAuthority, and the Account Authority updates the initial PuK-linkedaccount database by associating the customer-specific information withthe respective PuK-linked database record of that customer's device (asidentified by the public key of that device). Again, the AccountAuthority in this situation does not need to authenticate the newcustomer with respect to any existing account.

[0144] An example of a new business method of establishing a initialPuK-linked account database in accordance with the second aspect of thepresent invention comprises establishing new customers for an Internetservice provider (ISP). First, a number of manufactured devices such asdongles, for instance, are manufactured in accordance with the firstaspect of the present invention and mailed to a plurality of prospectivecustomers of the ISP. Each dongle is packaged with a CD-ROM includingsoftware for setting up and connecting to the ISP and the Internet froma potential customer's computer. The dongle and CD-ROM also may bedistributed as an insert in a magazine, for example. Upon receipt, theprospective customer installs the software in his or her computer andattaches the dongle to an appropriate port of the computer. Then, whenthe computer connects with the ISP, an EC is communicated to the ISPthat includes a digital signature generated utilizing a private keyretained within the dongle as well as a public key retained within andexported from the dongle. Upon receipt of the EC, the ISP authenticatesthe message using the public key included with the message. Uponauthentication, then the ISP compares for a match the public keyreceived with the linked public keys in the initial PuK-linked accountdatabase and activates the account having the matching public key. Theaccount record may include a credit of 100 hours of free internetsurfing, for example, as a promotional introduction to the ISP. In thisexample, no customer-specific information is required and the account issetup under an anonymous framework.

[0145] Alternatively, the ISP may require customer-specific informationin order to activate the new account, including billing and credit cardinformation from the customer. Upon receipt thereof, the identifiedrecord in the PuK-linked account database is updated with thiscustomer-specific information and the account is activated. A resultingupdated PuK-linked account database 2040 of the ISP after activation ofseveral accounts might resemble, for instance, that of FIG. 20.

[0146] Upon activation of the account, the account preferably isassigned a unique account identifier that is included with each messagesent to the ISP for identifying the account to which the messagerelates. A User D or account number may serve as the account identifier.The public key is recorded in the PuK-linked account database whereby,upon identifying the appropriate account record with the accountidentifier, the digitally signed message is authenticated with theassociated public key. Alternatively, the public key itself may servesas the account identifier. In either case, access is granted to itsnetwork and the Internet by the ISP upon a successful authentication ofa digitally signed message (Factor A Entity Authentication).

[0147] Another example of a new business method utilizing theaforementioned establishment of a initial PuK-linked account database ofthis second aspect of the present invention comprises setting upexisting customers of a financial institution with IC cards to be usedas check cards. In this example, a number of IC cards are manufacturedin accordance with the first aspect of the present invention and mailedto a plurality of existing customers of the financial institution whohave requested the IC cards. Each manufactured IC card includes arespective initialization PIN that must be sent to the financialinstitution for activation of the IC card for use on the account. Therespective initialization PIN is mailed to each customer separately fromthe corresponding IC card. Furthermore, each IC card includes recordedtherein the account number of the customer to which it is mailed.

[0148] The database records of the IC cards recorded in the securedatabase are transmitted to the financial institution in a securemanner. Upon receipt, the database records represent the initialPuK-linked account database which then are updated and/or merged withthe records of the customers in a preexisting account databasemaintained by the financial institution, the resulting database being aPuK-linked account database. A resulting PuK-linked account database2140 might resemble, for instance, that of FIG. 21.

[0149] Upon separate receipt by each customer of the IC card andinitialization PIN, the customer first uses the IC card at an ATMmachine of the financial institution by entering the initialization PINand then communicating to the financial institution an EC including thePIN from the customer and account number from the IC Card digitallysigned with the IC card. Upon receipt of the EC, the financialinstitution authenticates the sender of the EC by retrieving theauthorized PIN from the identified account number in the EC andcomparing the authorized PIN with the PIN transmitted in the EC. Thefinancial institution similarly authenticates the message with thepublic key associated with the identified account number. Uponsuccessful verification of the PIN and successful messageauthentication, the financial institution activates the IC card withinthe record for use as a check card on the account. Furthermore, afteractivation of the IC card, messages in ECs representing transactions onthe account need only be digitally signed with the IC card and includethe account number of the customer. Such ECs need not include anypersonal information of the customer, such as the customer's name,billing address, a PIN, etc.

[0150] C. Establishing Multiple Third-Party Accounts With PuK-LinkedDatabase Record

[0151] The third aspect of the present invention includes establishingmultiple third-party accounts with a PuK-linked database record and isbased partially upon the first and second preferred embodiments of thefirst aspect of the present invention. In this regard, and withreference to FIG. 22, a device 2204 that generates digital signatures ismanufactured within a secure environment 2214. Before the device 2204 isreleased from the secure environment 2214, the public key 2218 of thedevice 2204 plus some other information is recorded as a database record2275 in a secure database 2210; preferably, the other informationincludes the Security Profile 2220 of the device 2204, as describedabove with respect to the first aspect of the present invention. Thedevice 2204 then is distributed to a customer 2232 and the customer 2232establishes a respective account with each one of a plurality of desiredAccount Authorities 2242,2244,2246.

[0152] In accordance with the third aspect of the present invention,each PuK-linked account of the customer 2232 is established based upon,at least in part, a communication of the PuK-linked database record 2248from the secure database 2210 to each of the desired Account Authorities2242,2244,2246. As set forth above, the PuK-linked database record 2248preferably includes the public key 2218 and Security Profile 2220 of thedevice 2204 linked thereto by the Secured Entity 2212. Furthermore, thedatabase record 2248 is communicated in a secure manner 2214′ so as topreserve the integrity of the database record 2248.

[0153] When received by a respective Account Authority 2242,2244,2246,the public key 2218 linked to the Security Profile 2220 of the databaserecord 2248 represents an initial PuK-linked account database record ofthe customer 2232 with the respective Account Authority and, if thecustomer 2232 is an existing customer of the respective AccountAuthority, then the initial PuK-linked account database record 2248preferably is associated with the existing account database record ofthe customer 2232. However, the association of the PuK-linked accountdatabase record 2248 received from the Secure Entity 2212 with theexisting account database record of the customer 2232 preferably isperformed only after the receipt of the correct device 2204 by thecustomer 2232 has been verified through one or more of theaforementioned authentication techniques with regard to the secondaspect of the present invention.

[0154] If the initial PuK-linked account database record represents theonly account database record for the customer 2232 (i.e., if thecustomer is new to an Account Authority), then under a personalizedframework the customer 2232 supplies customer-specific information tothe Account Authority for recording with the initial PuK-linked accountdatabase record of the customer 2232. Under an anonymous framework, nocustomer-specific information need be provided.

[0155] Also under the personalized framework, the device 2204 isactivated for use on each account when the customer 2232 sends a messagedigitally signed using the device 2204 in a respective EC 2222 to eachAccount Authority 2242,2244,2246, and when the digitally signed messageis authenticated by the respective Account Authority 2242,2244,2246using the public key associated with the respective PuK-inked accountdatabase record 2248.

[0156] Under the anonymous framework, each respective accountestablished with an Account Authority 2242,2244,2246 is activated whenthe customer 2232 sends a message digitally signed using the device 2204in a respective EC 2222 to each Account Authority 2242,2244,2246, andwhen the digitally signed message is authenticated by the respectiveAccount Authority 2242,2244,2246 using the public key associated withthe respective PuK-linked account database record 2248.

[0157] D. Insuring Transactions Based on Identified SecurityCharacteristics of a Device That Generates Digital Signatures

[0158] The fourth aspect of the present invention includes the insuringof, a transaction represented by an EC that is digitally signed.Furthermore, the insurance preferably is provided on a per transactionbasis. For instance, a recipient represented for example by a financialinstitution that receives an EC instructing it to make a wire transferof $250,000 out of an account of one of its customers, and that isauthenticated, nevertheless may desire to insure that the EC is notfraudulent.

[0159] Reliable knowledge of security features of the device to whichbelongs the private key used to generate the digital signature of the ECconventionally has been lacking when such a transaction is insured. Anentity insuring the transaction (“Insuring Entity”), which gauges therisk that the EC was fraudulently sent and which calculates the premiumto be charged based on such risk, therefore would be forced to err onthe high side in insuring such transaction.

[0160] Now, in view of the first aspect of the present invention,security features Qf the device to which belongs the private key used togenerate the digital signature of the EC can be reliably identified.Moreover, the manufacturing history of the device also can be reliablyidentified at the same time. Accordingly, the risk that a particulardigitally signed EC has been fraudulently sent can be gauged withgreater accuracy, and it is believed that the premium charged for suchinsurance may be lowered based on this greater knowledge and theconsequent reduced risk of the transaction. Additionally, this greaterknowledge gives rise to a more targeted premium structure for insuring aplurality of transactions, wherein different rates are based, at, leastin part, on the varying identified security features of devicesgenerating digital signatures.

[0161] A system in which preferred embodiments of this fourth aspect ofthe present invention are implemented is illustrated in FIG. 23, whereina plurality of devices 2304 are manufactured at a secure manufacturingfacility 2302 in a secure environment 2314 in accordance with the firstaspect of the present invention. Each of the devices 2304 includes aprivate key retained therein for which a public key 2318 correspondingthereto is linked with a Security Profile 2320 thereof in a securedatabase 2310 maintained by a Secure Entity 2312. After manufacture, thedevices 2304 are released from the secure environment 2314 into theworld 2306, with one of the devices ultimately reaching a customer of aFinancial Institution 2350 and becoming associated with an account ofthe customer maintained at the Financial Institution 2350.

[0162] In accordance with a first preferred embodiment of this fourthaspect of the present invention, and as illustrated in FIGS. 24-28, adigital signature is generated (Step 2502) for a message including arequest for a wire transfer of $250,000 from the account of the customermaintained at the financial institution 2350. The digital signature iscombined (Step 2504) with the message for the wire transfer to form anEC 2322 that is then sent (Step 2506) from somewhere in the world 2306to the Financial Institution 2350. The EC 2322 preferably includes thenumber for the account from which the transfer is to be made.

[0163] Upon receipt (Step 2602) of the EC 2322, the FinancialInstitution 2350 authenticates (Step 2604) the message of the EC 2322using the public key associated with the account identified in the EC2322, and then determines whether to honor the instruction contained inthe EC 2322 and, if so, whether to insure the transaction represented bythe EC 2322. The determination of whether to honor the instructionpreferably is based, at least in part, upon the security features andmanufacturing history identified in accordance with the first aspect ofthe present invention.

[0164] Upon an affirmative determination to insure the transactionrepresented by the EC 2322, the Financial Institution 2350 forwards(Step 2606) the EC 2322 to the Insuring Entity 2352 is together with thepublic key. Upon receipt (Step 2702), the Insuring Entity 2352authenticates (Step 2704) the message of the EC 2322 with the public keyto confirm authentication of the message and, upon successfulauthentication, the Insuring Entity 2352 sends (Step 2706) the publickey to the Secure Entity 2312.

[0165] Upon receipt (Step 2804) of the public key, the Secure Entity2312 compares (Step 2806) for a match the public key against the linkedpublic keys maintained in the secure database 2310. If a match is found,then the Security Profile linked with the matching public key isretrieved (Step 2808) and, for the purpose of maintaining the integrityof the information during transit, digitally signed (also in Step 2808)by the Secure Entity 2312 to from a Security Certificate 2326. TheSecurity Certificate 2326 then is sent (Step 2810) to the InsuringEntity 2352. Preferably, the matching public key is included in theSecurity Certificate 2326 for confirmation by the Insuring Entity 2352of the public key to which the Security Certificate 2326 pertains. Uponreceipt (Step 2708) of the Security Certificate 2326 by the InsuringEntity 2352, the authenticity of the Security Certificate 2326 isconfirmed (also Step 2708) using a public key 2428 (SE PuK) of theSecure Entity 2321, which preferably is communicated (Step 2802) to theInsuring Entity 2352 beforehand. Subsequently, the Security Profilecontained in the authenticated Security Certificate 2326 is identifiedby the Insuring Entity 2352 as the Security Profile of the manufactureddevice to which belongs the private key used in digitally signing themessage of the EC 2322.

[0166] Based on the identified Security Profile, the Insuring Entity2352 is able to gauge a risk that the private key of the manufactureddevice was fraudulently used in digitally signing the message of the EC2322 and, in turn, the Insuring Entity 2352 is able to classify thetransaction thereof for a corresponding premium rate. The correspondingpremium rate for the particular classification of the transaction thenis applied to the monetary value of the transaction for which insuranceis sought (i.e., to the $250,000 in the present wire transfer example),and the actual premium to be charged for the particular transaction inquestion is calculated. Confirmation 2354 of insurance coverage then issent (Step 2710) by the Insuring Entity 2352 to the FinancialInstitution 2350. The coverage confirmation 2354 preferably includes theidentified Security Profile, applicable premium rate, and calculatedpremium to be charged to the Financial Institution 2350 for theparticular transaction represented by the EC 2322. The coverageconfirmation 2354 also is preferably digitally signed by the InsuringEntity 2352 to preserve the integrity of the coverage confirmation 2354during transit. Upon receipt and authentication (Step 2608) of thecoverage confirmation 2354, the Financial Institution 2350 makes (Step2610) the requested wire transfer 2356.

[0167] As in the first preferred embodiment, in the second preferredembodiment of the fourth aspect of the present invention, a plurality ofdevices are manufactured at a secure manufacturing facility in a secureenvironment. Each of the devices includes a private key retained thereinfor which a public key corresponding thereto is linked with a SecurityProfile thereof in a secure database maintained by a Secure Entity.After manufacture, the devices are released from the secure environmentinto the world, with one of the devices ultimately reaching a customerof a Financial Institution and becoming associated with an account ofthe customer maintained at the Financial Institution.

[0168] Unlike the first preferred embodiment, and as illustrated inFIGS. 29-33, the second preferred embodiment differs from the firstpreferred embodiment of the fourth aspect of the present invention inthat the Secure Entity 2912 creates and communicates a reference 2930containing public keys and corresponding Security Profiles ofmanufactured devices to the Insuring Entity 2952, rather than sending aSecurity Certificate for a particular one of the manufactured devices asin the first preferred embodiment of FIGS. 24-28. Nor does the InsuringEntity 2952 send a public key to the Secure Entity 2912 for identifyinga Security Profile from a secure database 2910.

[0169] With particular regard to the sequence of events, the SecureEntity 2912 generates (Step 3304) the reference 2930 containing publickeys and linked security features for all of the devices associated withthe accounts of the Financial Institution 2950, and then forwards (Step3306) the reference 2930 to the Insuring Entity 2952. The informationregarding which devices are associated with the accounts of theFinancial Institution 2950 is known by the Secure Entity 2912 in thesecond and third aspects of the present invention and, alternatively, isidentified to the Secure Entity 2912 by either the Financial Institution2950 or by the Insuring Entity 2952. The reference 2930 preferably iscompiled in accordance with the first aspect of the present invention asillustrated in FIGS. 7-11, and preferably is digitally signed by theSecure Entity 2912 to preserve the integrity of the information thereinduring transit and storage. A public key 2928 of the Secure Entity 2912is preferably communicated (Step 3302) in a secure manner to theInsuring Entity 2952 beforehand. Upon receipt thereof (Steps 3202 and3204), the Insuring Entity 2952 authenticates (Step 3206) the reference2930 with the public key 2928 of the Secure Entity 2912.

[0170] Thereafter, a digital signature is originated (Step 3002) for andcombined (Step 3004) with a message that includes a wire transferrequest for a particular account number maintained at the FinancialInstitution 2950 to form an EC 2922. The EC 2922 then is sent (Step3006) to the Financial Institution 2950. Upon receipt (Step 3102) of theEC 2922, the Financial Institution 2950 authenticates (Step 3104) themessage of the EC 2922 using the public key associated with the accountidentified in the EC 2922, and then determines whether to honor theinstruction contained in the EC 2922 and, if so, whether to insure thetransaction represented by the EC 2922. The determination of whether tohonor the instruction preferably is based, at least in part, upon thesecurity features and manufacturing history identified in accordancewith the first aspect of the present invention.

[0171] Upon an affirmative determination to insure the transactionrepresented by the EC 2922, the Financial Institution 2950 forwards(Step 3106) the EC 2922 to the Insuring Entity 2952 together with thepublic key. Upon receipt (Step 3208) of the EC 2922, the Insuring Entity2952 authenticates (Step 3210) the message of the EC 2922 with thepublic key to confirm authentication of the message and, upon successfulauthentication, the Insuring Entity 2952 compares for a match the publickey against the linked public keys in the reference 2930 to identify(Step 3212) a matching public key and the Security Profile linkedtherewith. The Security Profile thereby identified represents theSecurity Profile of the manufactured device to which belongs the privatekey used in digitally signing the message of the EC 2922.

[0172] Based on the identified Security Profile, the Insuring Entity2952 is able to gauge a risk that the private key of the manufactureddevice was fraudulently used in digitally signing the message of the EC2922 and, in turn, the Insuring Entity 2952 is able to classify thetransaction thereof for a corresponding premium rate. The correspondingpremium rate for the particular classification of the transaction thenis applied to the monetary value of the transaction for which insuranceis sought (i.e., to the $250,000 in the present wire transfer example),and the actual premium to be charged for the particular transaction inquestion is calculated. Confirmation 2954 of insurance coverage is thensent (Step 3214) by the Insuring Entity 2952 to the FinancialInstitution 2950. The coverage confirmation 2954 preferably includes theidentified Security Profile, applicable premium rate, and premium to becharged to the Financial Institution 2950 for the particular transactionof the EC 2922. The coverage confirmation 2954 also is preferablydigitally signed by the Insuring Entity 2952 to preserve the integrityof the coverage confirmation 2954 during transit. Upon receipt andauthentication (Step 3108) of the coverage confirmation 2954, theFinancial Institution 2950 makes (Step 3110) the requested wire transfer2956.

[0173] In a variation of this second preferred method of the fourthaspect of the present invention, as illustrated in FIGS. 34-38, a SecureEntity 3412 communicates a reference 3430 to a Financial Institution3450 rather than to an Insuring Entity 3452. The reference 3430 then isforwarded to the Insuring Entity 3452 by the Financial Institution 3450.Otherwise, the steps are the same as those described with reference tothe second method of the fourth aspect of the present inventionillustrated in FIGS. 29-33.

[0174] In particular, the Secure Entity 3412 creates (Step 3802) thereference 3430 including the public keys and linked security featuresfor all of the devices associated with the accounts of the FinancialInstitution 3450, and then sends (Step 3804) the reference 3430 to theFinancial Institution 3450. Upon receipt (Step 3602), the FinancialInstitution 3450 sends (Step 3604) the reference 3430 to the InsuringEntity 3452 and, in turn, the Secure Entity 3412 sends (Step 3806) itspublic key 3428 to the Insuring Entity 3452 in a reliable manner. Uponreceipt of the reference 3430 (Step 3702) and the public key 3428 of theSecure Entity 3412 (Step 3704), the Insuring Entity 3452 authenticates(Step 3706) the reference 3430.

[0175] Thereafter, a digital signature is originated (Step 3502) for andcombined (Step 3504) with a message regarding the wire transfer to forman EC 3422. The EC 3422 is then sent (Step 3506) to the FinancialInstitution 3450. Upon receipt (Step 3606) of the EC 3422, the FinancialInstitution 3450 authenticates (Step 3608) the message of the EC 3422using the public key associated with the account identified in the EC3422 from which the transfer is to be made, and then determines whetherto honor the instruction contained in the EC 3422 and, if so, whether toinsure the transaction represented by the EC 3422. The determination ofwhether to honor the instruction preferably is based, at least in part,upon the security features and manufacturing history identified inaccordance with the first aspect of the present invention.

[0176] Upon an affirmative determination to insure the transactionrepresented by the EC 3422, the Financial Institution 3450 forwards(Step 3610) the EC 3422 to the Insuring Entity 3452 together with thepublic key. Upon receipt (Step 3708) of the EC 3422, the Insuring Entity3452 authenticates (Step 3710) the message of the EC 3422 with thepublic key to confirm authentication of the message and, upon successfulauthentication, the Insuring Entity 3452 compares for a match the publickey against the linked public keys in the reference 3430 to identify(Step 3712) a matching public key and the Security Profile linkedtherewith. The Security Profile thereby identified represents theSecurity Profile of the manufactured device to which belongs the privatekey used in digitally signing the message of the EC 3422.

[0177] Based on the identified Security Profile, the Insuring Entity3452 is able to gauge a risk that the private key of the manufactureddevice was fraudulently used in digitally signing the message of the EC3422 and, in turn, the Insuring Entity 3452 is able to classify thetransaction thereof for a corresponding premium rate. The correspondingpremium rate for the classification of the transaction then is appliedto the monetary value of the transaction for which insurance is sought(i.e., to the $250,000 in the present wire transfer example), and theactual premium to be charged for the particular transaction at questionis calculated Confimation 3454 of insurance coverage then is sent (Step3714) by the Insuring Entity 3452 to the Financial Institution 3450. Thecoverage confirmation 3454 preferably includes the identified SecurityProfile, applicable premium rate, and premium to be charged to theFinancial Institution 3450 for the particular transaction of the EC3422. The coverage confirmation 3454 also is preferably digitally signedby the Insuring Entity 3452 to preserve the integrity of the coverageconfirmation 3454 during transit. Upon receipt and authentication (Step3612) of the coverage confirmation 3454, the Financial Institution 3450makes (Step 3614) the requested wire transfer 3456.

[0178] In a third preferred method of the fourth aspect of the presentinvention, a Security Certificate is incorporated into the manufactureddevice itself prior to the release of the device from the secureenvironment in accordance with the third preferred embodiment of thefirst aspect of the present invention. Accordingly, as illustrated inFIGS. 39-43, when a suspect device originates (Step 4002) a digitalsignature somewhere in the world 3906, the Security Certificate isincluded (Step 4004) with the digital signature and message in an EC3922, which then is sent (Step 4006) to a Financial Institution 3950.Upon receipt (Step 4102) of the EC 3922 by the Financial Institution3950, the public key identified in the Security Certificate is used toauthenticate (Step 4104) the message. Thereafter, if insurance isdesired for the transaction, the Financial Institution 3950 forwards(Step 4106) the EC 3922 to the Insuring Entity 3952. The determinationof whether to honor the instruction preferably is based, at least inpart, upon the security features and manufacturing history identified inthe Security Certificate in accordance with the first aspect of thepresent invention.

[0179] Upon receipt (Step 4204), the Insuring Entity 3952 authenticates(Step 4206) the message with the public key set forth in the SecurityCertificate to confirm authentication of the message. The InsuringEntity 3952 also authenticates (Step 4208) the Security Certificate withthe public key 3928 of the Secure Entity 3912, which preferably iscommunicated (Step 4302) by the Secure Entity 3912 and received (Step4202) by the Insuring Entity 3952 beforehand. The Security Profile ofthe manufactured device to which properly belongs the private key usedin generating the digital signature for the message of the EC 3922thereby is identified to the Insuring Entity 3952.

[0180] Based on the identified Security Profile, the Insuring Entity3952 is able to gauge a risk that the private, key of the manufactureddevice was fraudulently used in digitally signing the message of the EC3922 and, in turn, the Insuring Entity 3952 is able to classify thetransaction thereof for a corresponding premium rate. The correspondingpremium rate for the classification of the transaction then is appliedto the monetary value of the transaction for which insurance is sought(i.e., to the $250,000 in the present wire transfer example), and theactual premium to be charged for the particular transaction at questionis calculated. Confirmation 3954 of insurance coverage then is sent(Step 3714) by the Insuring Entity 3952 to the Financial Institution3950. The coverage confirmation 3954 preferably includes the identifiedSecurity Profile, applicable premium rate, and premium to be charged tothe Financial Institution 3950 for the particular transaction of the EC3922. The coverage confirmation 3954 also is preferably digitally signedby the Insuring Entity 3952 to preserve the integrity of the coverageconfirmation 3954 during transit. Upon receipt and authentication (Step3612) of the coverage confirmation 3954, the Financial Institution 3950makes (Step 3614) the requested wire transfer 3956.

[0181] Under any of the preferred methods of the fourth aspect of thepresent invention, the actual billing of the premium by an insuringentity to a Financial Institution preferably is performed on a regularlyscheduled period, such as monthly. Furthermore, the premium rates foreach transaction classification preferably are determined in accordancewith a prearranged insurance contract entered into between the FinancialInstitution and Insuring Entity. In this regard, the greater thesecurity level met by a device at the time of the transaction, the lowerthe premium rate should be. Furthermore, the coverage confirmations ofall insured transactions for a time period received by the FinancialInstitution readily may be utilized by the Financial Institution to keepa running tab on the amount of the premium to be billed by the InsuringEntity for such time period.

[0182] Preferably, the steps set forth above with regard to FIGS. 26-28;FIGS. 31-33; FIGS. 36-38; and FIGS. 41-43 are computer automated, andthe entire sequence of steps for each respective group of figures occurswithin a small time interval on the order of magnitude of at leastminutes, if not seconds.

[0183] As opposed to insurance provided on a per transaction basis,insurance also may be provided on a per device basis, possibly subjectto certain limits. In this case, each EC would not be sent to theInsuring Entity as in the preferred methods in which insurance isprovided on a per transaction basis. Rather, under this scenarioinsurance preferably is provided to an Account Authority (such as afinancial institution) for transactions of the Account Authority'scustomers who send digitally signed messages. In accordance with thefourth aspect of the present invention, each message is digitally signedwith a retained private key of a device manufactured in accordance withthe first aspect of the present invention, i.e., a manufactured devicefor which information preferably such as the Security Profile reliablyis identified. For example, a financial institution that maintains aPuK-linked account database of its customers that is established undereither of the second or third aspects of the present invention, andwhich includes the identified Security Profiles in the PuK-linkedaccount database records, may obtain insurance for all devices of itscustomers in accordance with the fourth aspect of the present invention.The insurance is provided for each device at a premium that is based, atleast in part, on the identified Security Profile of the device to whichthe device's public key is linked. The ability reliably to know theSecurity Profile of each device as, provided by the first aspect of thepresent invention permits differentiation in premiums charged as betweenthe devices to reflect the different levels of risk that may beassociated with the devices.

[0184] E. Gauging Whether EC on Account is Fraudulent Based onPuK-Linked Information of Device Generating Digital Signatures

[0185] A fifth aspect of the present invention includes gauging the riskof whether a message of an EC representing a transaction on an accountand digitally signed with a device is fraudulent and, based thereon,determining whether to perform the transaction. Gauging of the risk isbased on identified information that was securely linked with a publickey of the device at the time of its manufacture, including the securityfeatures and manufacturing history of the device, and preferablyincorporates the first aspect of the present invention. Gauging of therisk also is based on additional factors, including the transactionalaccount history of digital signatures authenticated using the publickey, the environment in which the digital signature for the EC wasoriginated, and other account or business-specific factors, such aswhether the transaction is even capable of being performed on theaccount.

[0186] An example of an account database maintained by an AccountAuthority for a plurality of user accounts in accordance with the fifthaspect of the present invention is illustrated in FIG. 44. This accountdatabase corresponds with that of FIG. 21 with “Transactional History”and “PuK-to-Account Authentication” information for each account beingadded to the account records in conjunction with the Security Profile toform “Risk Management Information.” The security features andmanufacturing history of the device, as well as the public key linkedtherewith, are associated with the account and may be obtained by anAccount Authority as set forth above with respect to the first, second,or third aspects of the present invention, or through any other processconsidered trustworthy by the Account Authority.

[0187] The transactional account history is recorded on the account bythe Account Authority, preferably as digitally signed ECs are received.In particular, the Account Authority records the transaction details ofeach EC in a record of the account. The transactional history mayinclude such factors as the geographic locations of use, amounts oftransaction, and frequency of transactions, all of which may be trackedand evaluated by the Account Authority in monitoring for possible fraud.Information such as the number of incorrect entries of data representinga Secret or biometric characteristic used to authenticate a user of thedevice also may be monitored by the Account Authority, which also mayserve to indicate possible fraud.

[0188] The PuK-to-Account Authentication is the authentication techniqueemployed when the public key and PuK-linked information were associatedwith the account maintained by the Account Authority. This informationis important in evaluating the risk to be accorded the initialassociation of the public key and PuK-linked information with theaccount.

[0189] Also in accordance with the fifth aspect of the presentinvention, the Account Authority notes any factors known about theenvironment in which the digital signature for the message wasoriginated. Indeed, the environment in which the device is used often iscommunicated within the EC itself. For example, in financialtransactions involving credit charges, an Account Authority—such as anissuing bank—is able to determine whether a card was present at a pointof sale for a transaction, or whether the charge occurred otherwise,such as over the Internet. The former scenario is believed to involve arisk of fraud that is substantially less than that of the laterscenario. In another example, when an external apparatus such as an I/Osupport element is used in conjunction with a device to compose amessage and originate a digital signature, information regarding the I/Osupport element is preferably included in the environmental informationcommunicated in the EC. For instance, an I/O support element also maydigitally sign an EC, and information regarding the I/O support elementlinked to the public key of the I/O support element preferably isidentified in accordance with the first aspect of the present inventionindeed, the device may include a card reader comprising hardware andsoftware components designed in accordance with the technicalspecifications published by CEN/ISSS as a result of the well-knownFinancial Transactional IC Card Reader Project (known commonly as“FINREAD”).

[0190] A preferred embodiment in accordance with this aspect of thepresent invention is illustrated in FIG. 45, wherein an AccountAuthority receives (Step 4502) an EC including a message and a digitalsignature therefor. The digitally signed message includes an instructiontherein representing a transaction on a particular account as identifiedin the EC by a unique account number. Upon receipt, the AccountAuthority retrieves (Step 4504) a public key associated with theparticular account and then attempts to authenticate (Step 4506) themessage of the EC using the public key. If the message does notauthenticate in Step 4508, then the Account Authority rejects (Step4510) the message. If the message authenticates in Step 4508, then theAccount Authority further processes (Step 4512) the message.

[0191] Further processing (Step 4512) of the message includesconsideration (Step 4514) of numerous factors that are used by theAccount Authority to gauge the risk that the digital signature wasfraudulently generated and, ultimately, to determine whether to performthe transaction on the account. The consideration (Step 4514) includesan evaluation (Step 4516) of the security features and manufacturinghistory of the device linked with the public key of the device withinthe environment of the manufacturing of the device and, as applicable:an evaluation (Step 4518) of entity authentication provided by thesender of the EC or user of the device; an evaluation (Step 4520) ofenvironmental factors surrounding the origination of the EC; anevaluation (Step 4522) of the transactional history of the device on theaccount; and an evaluation (Step 4524) of other account orbusiness-specific factors. At a more fundamental level, thePuK-to-Account Authentication also may be considered in gauging the riskof fraud.

[0192] Whether the Account Authority considers some or all of the abovefactors, how much weight the Account Authority applies to any particularfactor, and what order the Account Authority makes these evaluations mayvary, and the Account Authority uses its own business rules and judgmentto determine (Step 4526), based on its own considerations in Step 4514,whether to perform the transaction on the account. If the determinationin Step 4526 is negative, then the Account Authority rejects (Step 4510)the message. If the determination in Step 4526 is positive, then theAccount Authority performs (Step 4528) the transaction on the accountand updates (Step 4530) the account record accordingly. Alternatively,the Account Authority may choose to execute only a limited portion ofthe instruction (not shown) based on its considerations (Step 4514), orthe Account Authority may require additional information from the senderof the EC prior to performing the transaction (not shown).

[0193] In a feature of the present invention, a plurality of differentdevices are associated with the same user account maintained with theAccount Authority. In this situation, the risk of a fraudulenttransaction preferably is gauged not on an overall account basis, butrather, on a device-by-device basis for each account. Specifically, thetransactional history of digital signatures on the account preferably isrecorded and later considered on a device-by-device basis.

[0194] Of course, the actual rule base or business logic used by eachAccount Authority is subjective and necessarily will vary as betweenAccount Authorities. Nevertheless, the reliable identification of thesecurity features and manufacturing history of a device—when combinedwith evaluations of the transactional account history of digitalsignatures generated by the device, environmental factors in which thedigital signature is originated, and other account or business-specificfactors—provides added security against fraudulent transactions nototherwise realized.

[0195] F. Disseminating PuK-Linked Information of Device GeneratingDigital Signatures

[0196] In accordance with a sixth aspect of the present invention, anentity (herein “Central Key Authority”) maintains certain PuK-linkedaccount information of a user (herein “Registration Information”) fordisseminating to one or more Account Authorities. The RegistrationInformation includes the public key (PuK) of a device of the user thatgenerates digital signatures and one or more of the following types ofinformation: the identity of Account Authorities with which the user hasPuK-linked accounts for the device and respective account identifiersthat identify each PuK-linked account of the user to the respectiveAccount Authority; information linked with the public key of the devicein accordance with the first aspect of the present invention;user-specific information, such as the user's mailing address, creditcard information, age, etc.; and, as desired, the authenticationtechniques that were employed in verifying the user-specific informationmaintained by the Central Key Authority. Furthermore, the Central KeyAuthority preferably indexes the Registration Information of the user toa unique account identifier such that the Registration Information maybe retrieved based on the account identifier. In this regard, but notshown, the public key may serve as the unique account identifier. Anexample of a PuK-linked account database 4640 of a Central Key Authorityis illustrated in FIG. 46.

[0197] In accordance with this aspect of the present invention, theCentral Key Authority disseminates some or all of the RegistrationInformation, as appropriate, to Account Authorities. RegistrationInformation is disseminated when the user has an account with an AccountAuthority—or desires to establish an account with an AccountAuthority—and desires to send ECs with messages each containing aninstruction that represents a transaction on the account, each suchmessage being digitally signed using the device. The dissemination ofthe Registration Information occurs, for example, when RegistrationInformation maintained by an Account Authority has become outdated for aparticular account. Furthermore, the dissemination of the RegistrationInformation may be in accordance with the third aspect of the presentinvention wherein the PuK-linked account database record is obtainedfrom the Central Key Authority if the Central Key Authority isconsidered to have sufficient security measures and protocols so as toqualify to be a Secure Entity.

[0198] The Registration Information maintained by the Central KeyAuthority is obtained in various ways. For example, the public key andinformation linked therewith preferably is obtained from a Secure Entityin accordance with the first, second, or third aspects of the presentinvention. The identity of the Account Authorities with which the userhas PuK-linked accounts for the device, and the account identifier thatidentifies the PuK-linked account of the user to each such AccountAuthority, preferably is obtained from the user, and is obtained whenthe user registers with the Central Key Authority; when, at theinstruction of the user, the Central Key Authority establishes anaccount on behalf of the user with an Account Authority; or when thethird-party, at the instruction of the user, acquires RegistrationInformation from the Central Key Authority.

[0199] An example of efficiency and convenience that may be provided bythe Central Key Authority in accordance with this sixth aspect of thepresent invention comprises the updating of PuK-linked accounts of auser with a new device of the user in place of the user's old (andpossibly outdated) device as represented by the respective public keysof the devices. With reference to FIGS. 47-51, such an update preferablyis accomplished by a user 4758 by the mere sending (Step 4806) of an EC4722 to a Central Key Authority 4760 with which the user 4758 haspreviously registered with an old device as represented by the oldpublic key (PuK1).

[0200] The EC 4722 includes a message (M) having an instruction toassociate a new public key (PuK2) included in the message with accountsof the user 4758 maintained by certain Account Authorities 4762,4764,which preferably are on register with the Central Key Authority 4760.The message is digitally signed (Step 4802) using the private key(PuK1), and the digital signature (DS) therefor is included (Step 4804)with the message in the EC 4722. The EC 4722 also includes the accountidentifier (CKA#) for the account maintained by the Central KeyAuthority 4760.

[0201] Upon receipt (Step 4902) of the EC 4722, the Central KeyAuthority 4760 authenticates (Step 4904) the message (M) of the EC 4722using the public key (PuK1) associated with the account of the user 4758maintained by the Central Key Authority 4760 as identified by the uniqueaccount identifier (CKA#).

[0202] Upon successful authentication, the Central Key Authority 4760updates (Step 4906) the Registration Information with the new public key(PuK2) and sends (Step 4908) a respective EC 4766,4768 to each of theAccount Authorities 4762,4764 identified by the user 4758. Each EC4762,4764 includes a respective request of the Account Authorities4762,4764 to associate the new public key (PuK2) with the accounts ofthe user 4758. The Central Key Authority 4760 also preferably obtainsthe Security Profile linked with the new public key (PuK2) in accordancewith the first aspect of the present invention, and includes theSecurity Profile with the new public key (PuK2) in the respectiverequest sent to the Account Authorities 4762,4764.

[0203] The request preferably is digitally signed. (Step 4908) using aprivate key of the Central Key Authority 4760 for authentication of therequest and information therein by each Account Authority 4762,4764, andmay include the original EC 4722 received by the Central Key Authority4760 from the user 4758. Each respective request also preferablyincludes the appropriate account identifier for the account that is' tobe updated by each Account Authority 4762,4764, which information ispart of the Registration Information maintained by the Central KeyAuthority 4760.

[0204] Upon receipt (Step 5002) of the EC 4766 by Account Authority4762, the request (R1) is authenticated (Step 5004) using a public keyof the Central Key Authority 4760, which preferably is obtained by theAccount Authority 4762 beforehand. The Account Authority 4762 also mayauthenticate the original message (M) in EC 4722, as desired. Uponsuccessful authentication, the Account Authority 4762 updates (Step5006) the account identified by the account identifier (Acc#) in the EC4766 by associating the new public key (PuK2) with the account.

[0205] Similarly, upon receipt (Step 5102) of the EC 4768 by AccountAuthority 4764, the request (R2) is authenticated (Step 5104) using thepublic key of the Central Key Authority 4760, which preferably isobtained by the Account Authority 4764 beforehand. The Account Authority4764 also may authenticate the original message (M) in EC 4722, asdesired. Upon successful authentication, the Account Authority 4764updates (Step 5106) the account identified by the account identifier(Acc#) in the EC 4768 by associating the new public key (PuK2) with theaccount.

[0206] As will be appreciated by those having ordinary skill in the art,while two Account Authorities have been illustrated in the preferredmethod of FIGS. 47-51, any number of Account Authorities may be sent arespective EC by the Central Key Authority as appropriate and desired.Indeed, the more Account Authorities that are contacted, the moreefficient and convenient the preferred method in accordance with thesixth aspect of the present invention.

[0207] Accordingly, it readily will be understood by those personsskilled in the art that, in view of the above detailed description ofpreferred embodiments, devices, and methods of the present invention,the present invention is susceptible of broad utility and application.Many methods, embodiments, and adaptations of the present inventionother than those herein described, as well as many variations,modifications, and equivalent arrangements, will be apparent from orreasonably suggested by the present invention and the following detaileddescription thereof, without departing from the substance or scope ofthe present invention. Furthermore, those of ordinary skill in the artwill understand and appreciate that although steps of various processesmay be shown and described in some instances as being carried out in apreferred sequence or temporal order, the steps of such processes arenot necessarily to be limited to being carried out in such particularsequence or order. Rather, in many instances the steps of processesdescribed herein may be carried out in various different sequences andorders, while still falling within the scope of the present invention.Accordingly, while the present invention is described herein in detailin relation to preferred methods and devices, it is to be understoodthat this detailed description only is illustrative and exemplary of thepresent invention and is made merely for purposes of providing a fulland enabling disclosure of the invention. The detailed description setforth herein is not intended nor is to be construed to limit the presentinvention or otherwise to exclude any such other embodiments,adaptations, variations, modifications and equivalent arrangements ofthe present invention, the present invention being limited solely by theclaims appended hereto and the equivalents thereof.

[0208] For instance, the roles set forth above with respect to theSecure Manufacturing Facility, the Secure Entity, the Account Authority,the Financial Institution, the Insuring Entity, and the Central KeyAuthority, may all be performed by a single entity or affiliatedentities, or any combination thereof, in accordance with the presentinvention. Moreover, any of the aforementioned entities also may be arecipient of an EC.

[0209] Additionally, it should be apparent that the devices describedabove with regard to the present invention encompass, for example,devices of merchants and other commercial entities that generate digitalsignatures, and are not limited to devices of individual consumers thatgenerate digital signatures. For instance, a device in accordance withthe present invention includes an I/O support element comprising, forexample, an IC card reader used to read IC cards of individual consumersin establishing secure, financial transactions if such IC card readeritself generates digital signatures. In this regard, such device mayinclude a trusted platform module.

What is claimed is:
 1. A method in which information of a device thatgenerates digital signatures is reliably identified, comprising thesteps of: (a) for each of a plurality of devices manufactured in anenvironment, (i) creating a public-private key pair within theenvironment, (ii) linking within the environment in a secure manner thepublic key with other information associated with the device, and (iii)before release of the device from the environment, storing the privatekey within the device for utilization in generating a digital signaturefor an electronic message; and (b) thereafter, when a said linked publickey successfully authenticates a digitally signed message, identifyingthe other information associated with said linked public key aspertaining to the device to which belongs the private key utilized indigitally signing the message.
 2. The method of claim 1, wherein thesecure manner of linking comprises recording the linked public keys andSecurity Profiles in a database and maintaining the database in anenvironment having a security rating at least comparable to a securitylevel of each device for which the public key thereof is linked.
 3. Themethod of claim 1, wherein the secure manner of linking comprises: (a)originating a digital signature for a reference including the linkedpublic key and a Security Profile of the device; (b) publishing thereference and digital signature therefor; and (c) maintaining theprivate key utilized in originating the digital signature for thereference in an environment having a security rating that is at leastcomparable to a security level of the device to which the referencepertains.
 4. The method of claim 1, wherein the other information isidentified by a recipient of the digitally signed message.
 5. The methodof claim 1, wherein the other information is identified to a recipientof the digitally signed message.
 6. A method of managing a database forreliably identifying a Security Profile of a device that generatesdigital signatures, comprising the steps of (a) maintaining the databasein a secure environment; (b) recording in the database for each one of aplurality of devices manufactured in the secure environment, (i) apublic key of a public-private key pair of the manufactured device, andin association therewith, (ii) a Security Profile of the manufactureddevice, the public key and Security Profile thereby being securelylinked together; and (c) thereafter, when a said linked public keysuccessfully authenticates a digitally signed message, identifying theSecurity Profile associated with said linked public key as pertaining tothe manufactured device to which belongs the private key utilized indigitally signing the message.
 7. The method of claim 6, wherein theSecurity Profile is identified by a recipient of the digitally signedmessage.
 8. The method of claim 6, wherein the Security Profile isidentified to a recipient of the digitally signed message.
 9. A methodof managing a database for reliably identifying a Security Profile of adevice that generates digital signatures, comprising the steps of: (a)maintaining the database in a secure environment, (b) recording in thedatabase for each one of a plurality of devices manufactured in thesecure environment, (i) a public key of a public-private key pair of themanufactured device, and in association therewith, (ii) a SecurityProfile of the manufactured device, the public key and Security Profilethereby being securely linked together; and (c) communicating areference in a secure manner, the reference including the public key andSecurity Profile linked therewith for at least one of the manufactureddevices.
 10. The method of managing a database of claim 9, wherein saidcommunicating the reference in a secure manner comprises originating adigital signature for a database record of a manufactured devicemaintained in the database and publishing the digital signature and thedatabase record.
 11. The method of managing a database of claim 9,wherein said communicating the reference in a secure manner comprisescommunicating the reference to a recipient of a digitally signed messagein a manner having a security rating that is at least comparable to asecurity level of each manufactured device to which the referencepertains.
 12. The method of managing a database of claim 9, furthercomprising successfully authenticating a digitally signed message with asaid linked public key of the reference and thereby identifying theSecurity Profile associated with said linked public key as pertaining tothe manufactured device to which belongs the private key utilized indigitally signing the message.
 13. The method of claims 6 or 12, furthercomprising the step of receiving the digitally signed message anddigital signature from a recipient thereof.
 14. The method of managing adatabase of claims 6 or 9, wherein the secure environment has asufficient security rating so as not to compromise the security level ofany of the devices manufactured therein for which the public key thereofis linked.
 15. The method of managing a database of claims 6 or 9,wherein the public key and Security Profile of each of the manufactureddevices are retrievable from the database based on a device identifierassigned for each of the manufactured devices.
 16. The method ofmanaging a database of claim 15, wherein the identifier for each of themanufactured devices comprises the respective public key of themanufactured device.
 17. The method of claim 15, wherein the identifierfor each of the manufactured devices comprises a respective serialnumber of each manufactured device.
 18. The method of claim 15, whereinthe identifier for each of the manufactured devices comprises arespective account number associated with each manufactured device. 19.The method of managing a database of claims 6 or 9, further comprisingreceiving a device identifier from a recipient of a digitally signedmessage and comparing for a match, is the device identifier with deviceidentifiers in the database to which the linked public keys and SecurityProfiles are indexed.
 20. The method of managing a database of claims 6or 9, further comprising receiving a suspect device public key from arecipient of the digitally signed message and comparing for a match thesuspect device public key with the linked public keys in the database towhich the Security Profiles are indexed.
 21. The method of claim 20,wherein the public key used to authenticate the electronic message issent with the digital signature for the electronic message.
 22. A methodof providing for reliably identifying a Security Profile of a devicethat generates digital signatures, comprising the steps of: (a) for eachof a plurality of devices manufactured in a secure environment,recording together the public key with a Security Profile of themanufactured device and generating a digital signature therefor tocollectively define a Security Certificate, the public key and SecurityProfile thereby being securely linked together; and (b) before eachmanufactured device is released from the secure environment,incorporating its respective Security Certificate into the manufactureddevice such that the Security Certificate is sent with a digitalsignature that is generated by the manufactured device using the privatekey.
 23. The method of claim 22, further comprising (a) generating adigital signature for an electronic message utilizing the private key ofone of the manufactured devices; (b) sending the Security Certificate ofthe particular manufactured device with the digital signature for theelectronic message; (c) successfully authenticating the electronicmessage using the public key included in the Security Certificate; (d)successfully authenticating the Security Certificate using anotherpublic key; and (e) identifying security features in the SecurityCertificate as being the security features of the particularmanufactured device to which belongs the private key utilized togenerate the digital signature of the electronic message.
 24. The methodof claim 22, wherein the secure environment has a sufficient securityrating so as not to compromise the security level of any of the devicesmanufactured therein for which the public key thereof is linked.
 25. Themethod of claims 1, 6, 12, or 23, further comprising gauging a risk thatthe private key was fraudulently used to digitally sign the messagebased at least in part on said identified Security Profile.
 26. Themethod of claims 1, 6, 9, or 22, wherein the Security Profile of adevice comprises security characteristics of the device.
 27. The methodof claim 26, wherein the security characteristics of a respectivemanufactured device include an algorithm used by the device inoriginating digital signatures.
 28. The method of claims 1, 6, 9, or 22,wherein the Security Profile of a device comprises authenticationcapabilities of the device.
 29. The method of claim 28, wherein theauthentication capabilities include whether the device performs Factor Aand Factor B Entity Authentication.
 30. The method of claims 1, 6, 9, or22, wherein the Security Profile of a device comprises all of thesecurity features of the device.
 31. The method of claims 28, whereinthe Security Profile of a device further comprises a manufacturinghistory of the device.
 32. The method of claim 29, wherein themanufacturing history includes a batch identifier of the device.
 33. Themethod of claim 29, wherein the manufacturing history includes theidentity of a manufacturer of the device.
 34. The method of claim 29,wherein the manufacturing history includes a part number of the device.35. The method of claim 29, wherein the manufacturing history includesthe date and location of manufacture of the device.
 36. The method ofclaim 29, wherein the manufacturing history includes the linked key ofthe device.
 37. The method of claim 29, wherein the manufacturinghistory includes a serial number of the device.
 38. The method of claim37, wherein the serial number of the manufactured device comprises thepublic key of the device.
 39. The method of claims 6, 9, or 22, whereineach device manufactured in the secure environment meets a definedsecurity level for secure devices.
 40. The method of claims 2, 3, 6, 9,or 22, wherein the secure environment includes multiple physicallocations.
 41. The method of claims 1, 6, 12, or 22, wherein theelectronic message represents a financial transaction.
 42. The method ofclaims 1, 6, 12, or 22, wherein the electronic message represents alegal action.
 43. The method of claims 1, 6, 12, or 22, wherein theelectronic message represents a request for access to information. 44.The method of claims 1, 6, 12, or 22, wherein the electronic messagerepresents a request for access to a physical location.
 45. The methodof claims 1, 6, 9, or 22, wherein each pair of keys of a manufactureddevice is created in the respective device.
 46. The method of claim 45,wherein only the public key of each pair is exportable from therespective device.
 47. The method of claim 45, wherein the private keyis not exportable from the respective device.
 48. The method of claims1, 6, 12, or 23, further comprising the step of providing a monetaryguarantee that the digital signature for the electronic message was notfraudulently originated in exchange for a premium that is based, atleast in part, upon said identified Security Profile.
 49. The method ofclaim 48, wherein the electronic communication is sent to a recipientand then forwarded to an entity providing the monetary guarantee. 50.The method of claim 48 wherein said authenticating is performed by anentity providing the monetary guarantee.
 51. The method of claim 48further comprising sending a confirmation of coverage to an insured byan entity providing the monetary guarantee.
 52. The method of claim 51,wherein the coverage confirmation includes security features of amanufactured device.
 53. The method of claim 52, wherein the coverageconfirmation further includes an indication of the premium for themonetary guarantee.
 54. The method of claim 48, wherein a secure entitylinks together a public key and security features of each manufactureddevice in the secure environment, and wherein the secure entitycommunicates a public key of the secure entity to an entity providingthe monetary guarantee for authentication of linked security features ofa manufactured device.
 55. The method of claim 48, further charging adifferent premium rate for the provision of the monetary guarantee basedon different Security Profiles of the devices.
 56. The method of claims1 or 6, further comprising the step of providing a monetary guaranteethat the digital signature for the electronic message was notfraudulently originated in exchange for a premium that is based, atleast in part, upon said identified Security Profile, and wherein anentity providing the monetary guarantee sends a public key successfullyauthenticating the electronic message to a secure entity which links inthe secure environment a respective public key to respective securityfeatures of each manufactured device.
 57. The method of claim 56,wherein the secure entity compares the public key successfullyauthenticating the electronic message with the public keys linked tosecurity features of the manufactured devices.
 58. The method of claim57, wherein the secure entity communicates security features to theentity providing the monetary guarantee for which the public key linkedthereto matches the public key successfully authenticating theelectronic message.
 59. The method of claim 58, wherein the secureentity digitally signs the communication of the security features. 60.The method of claims 1 or 9, further comprising the step of providing amonetary guarantee that the digital signature for the electronic messagewas not fraudulently originated in exchange for a premium that is based,at least in part, upon said identified Security Profile, and wherein asecure entity links a public key with security features of amanufactured device by digitally signing a reference including thepublic key and the security features of the manufactured device.
 61. Themethod of claim 60, wherein the secure entity communicates the referenceto a recipient of the electronic communication.
 62. The method of claim60, wherein the secure entity communicates the reference to an entitythat provides the monetary guarantee.
 63. The method of claim 62,wherein the entity that provides the monetary guarantee authenticatessaid digitally signed reference communicated by the secure entity.
 64. Amethod of establishing an initial PuK-linked account database,comprising the steps of: (a) maintaining the database in a secureenvironment; (b) recording in the database for each one of a pluralityof devices manufactured in the secure environment, (i) a public key of apublic-private key pair of the manufactured device, and m associationtherewith, (ii) a Security Profile of the manufactured device, thepublic key and Security Profile thereby being linked together, (c)distributing the manufactured devices from the secure environment to aplurality of users; and (d) identifying the database records of saiddistributed devices as the initial PuK-linked account database of theusers.
 65. The method of claim 64, wherein the manufactured devices aredistributed to potential customers and existing customers.
 66. Themethod of claim 64, wherein said step of identifying comprisescommunicating from the secure environment in a secure manner thedatabase records of said distributed manufactured devices to athird-party as the initial PuK-linked account database of thethird-party.
 67. The method of claim 66, wherein said step ofcommunicating the database records from the secure environment in asecure manner to the third-party comprises communicating the databaserecords in a manner having a security rating that is comparably greaterthan a security level met by each manufactured device to which thedatabase records pertain.
 68. The method of claim 66, wherein said stepof communicating the database records from the secure environment in asecure manner to the third-party comprises originating a digitalsignature for the database records and communicating the databaserecords and digital signature to the third-party.
 69. The method ofclaim 66, further comprising the step of updating the initial PuK-linkedaccount database with customer-specific information.
 70. The method ofclaim 66, further comprising merging the initial PuK-linked accountdatabase with a preexisting account database of the third-party.
 71. Themethod of claim 64, further comprising activating an account of thePuK-linked account database by: (a) originating a digital signature foran electronic message utilizing a private key of one of the manufactureddevices; (b) authenticating the message using a public key; (c)comparing the public key used to authenticate the message with the keysrecorded in the initial PuK-linked account database; and (d) when thepublic key matches a key recorded in a record of the initial PuK-linkedaccount database, activating the account corresponding to that record.72. The method of claim 71, wherein the public key used to authenticatethe electronic message is sent with the digital signature for theelectronic message.
 73. A method of establishing an initial PuK-linkedaccount database record of a user with each one of a plurality ofthird-parties, comprising the steps of: (a) manufacturing devices in asecure environment; (b) for each manufactured device, (i) generating apair of keys used in asymmetric cryptography, (ii) before it is releasedfrom the secure environment, storing one of the keys within themanufactured device for utilization in generating a digital signaturefor an electronic message, (iii) recording the other key and otherinformation in a secure database maintained within the secureenvironment; (c) distributing one of the manufactured devices from thesecure environment to the user; and (d) identifying the database recordof said distributed manufactured device to each one of the third-partiesas the initial PuK-linked account database record of the user.
 74. Themethod of claim 73, wherein said step of identifying the database recordcomprises communicating the database record from the secure database toeach of the third-parties in a secure manner.
 75. The method of claim73, wherein the user is a potential customer of one of thethird-parties.
 76. The method of claim 73, wherein the user is anexisting customer of one of the third-parties.
 77. The method of claim73, wherein said step of identifying comprises communicating from thesecure environment in a secure manner the database record of saiddistributed manufactured device to each of the third-parties as theinitial PuK-linked account database record for the user.
 78. The methodof claim 77, wherein said step of communicating the database record fromthe secure environment in a secure manner comprises communicating thedatabase record in a manner having a defined security level greater thana comparable security level of the manufactured device to which thedatabase record pertains.
 79. The method of claim 77, wherein said stepof communicating the database record from the secure environment in asecure manner comprises originating a digital signature for the databaserecord and communicating the database record and digital signature toeach of the third-parties.
 80. The method of claim 77, furthercomprising the step of updating the initial PuK-linked account databaserecord of the user received by one of the third-parties withuser-specific information.
 81. The method of claim 80, furthercomprising merging the initial PuK-linked account database record of theuser received by one of the third-parties with a preexisting accountdatabase record.
 82. The method of claim 73, further comprisingactivating an account of a PuK-linked account database of one of thethird-parties by: (a) generating a digital signature for an electronicmessage utilizing a private key of the manufactured device distributedto the customer; (b) sending the electronic message and digitalsignature to the third-party; (c) authenticating the message using apublic key; (d) comparing the public key used to authenticate themessage with keys recorded in a PuK-linked account database of thethird-party; and (e) when the public key matches a key recorded in arecord of the PuK-linked account database, activating the accountcorresponding to that record.
 83. The method of claim 82, wherein thepublic key used to authenticate the electronic message is sent with thedigital signature for the electronic message.
 84. A method ofmanufacturing devices that generate digital signatures such that eachdevice may be reliably and uniquely identified, the devices beingmanufactured within a secure environment, comprising the steps of: (a)creating a public-private key pair within the secure environment; (b)storing the private key within the device against the possibility ofdivulgement thereof by the device; and (c) securely linking the publickey with other information within the secure environment.
 85. The methodof claim 84, wherein each private-public key pair is created within eachdevice based on a random number produced by a random number generatordisposed within each device.
 86. The method of claim 85, wherein therandom number generator is a high quality random number generator. 87.The method of claim 85, wherein the only the public key is exportablefrom the device.
 88. The method of claim 85, wherein each digitalsignature generated by each device is a random number.
 89. The method ofclaim 85, wherein the other information comprises respective securityfeatures of each device.
 90. The method of claim 85, wherein the otherinformation comprises a manufacturing history of each device.